Well, just tried out the CGI functionality, and it is incredibly easy.
This code is all it takes to receive input through a URL in a browser and return a customized page:
CGI
Topic(href) //this is our entry point into the CGI program
var/page = "<center><H1>Submit!</H1></center>"
page += "You're in OUR website now."
page += "<BR><BR>"
page += "CGI.Topic() received: [href]"
usr << page
That's pretty amazing -- even the professional packages I've used couldn't do it that easily.
Of course we're not at the point of handling persistent user data or anything -- but this means I can now auto-generate my website if I so choose!
More importantly, it means we'll be able to add the screenshot functionality to DragonSnot very easily...
One little note for the documentation: this kept failing for me until I thought to turn on executable permissions for the .dmb file.
ID:138318
 Oct 31 2000, 10:13 pm (Edited on Oct 31 2000, 10:21 pm)
|
|
On 11/1/00 7:11 am Dan wrote:
It worked out very beautifully, because with only a tiny alteration, the whole html/form.dm library works in either BYOND or CGI mode. I will bet that the CGI functionality will be a very major aspect of future BYOND use. Some things that come to mind... The next step that web-based development environments usually take is providing some level of automated support for persistent data/user-login across pages. That is, either through data maintained in the URL or in a hidden form contained on each page, knowledge of the current web user is maintained, allowing the site to be fully customized to the user on each page and to maintain access controls for various information. For example...one thing I will probably do is webify my Forum library. Along with allowing conversations to occur in BYOND or on the web, this will give me the chance I've been wanting to majorly update that code to the new savefile stuff. Anyway, since each person using the forum needs to have a unique identity, I need to maintain their identity throughout the session, and for security reasons I need to have some way of not letting someone else simply doctor a URL so they can appear as an administrator. BYOND could evolve to completely handle this aspect of things (it can be a lot of work, so be warned!), and/or it could provide a few tools to make it easier for the designer to do it. The first thing that comes to mind is API for generating/decoding unique keys. If I had that (and that falls under "mathematical stuff I don't understand that Dan clearly does!"), then I would probably handle persistance and security like so: Each URL the Forum generated would contain a key based on the user's login and their password, and another key somehow incorporating the current time and the user's login (in a way that I could get the time back no matter when I check it). Each time they navigated a page, these would be decoded. If the login key was wrong or the time key showed that more than N seconds had passed, the Forum would go into view-only mode, screening out any private info and/or forcing the user to login again. Of course, Tom might have better suggestions, since he did the BYOND Forum, which uses logins and does not clutter up the URL with all this stuff. Maybe I could be doing hidden forms in POST mode? Anyway, things to think about and I'd be happy for any suggestions on how to proceed on that. A usability item: One thing I've noticed is that while the server has a way to know that a file is a CGI program (becase the admin registers the extension with it), the browser does not seem to be aware of this. So it tends to redisplay the page it already has rather than getting an update. I found myself having to force a refresh while testing things out. Is there any way around this? | |
On 11/1/00 10:10 am Deadron wrote:
On 11/1/00 7:11 am Dan wrote: The next step that web-based development environments usually take is providing some level of automated support for persistent data/user-login across pages. The good news is that your problem is effectively solved up at dantom.com, although we'll have to provide a bit more documentation and components for it. Web pages hosted at dantom.com have access to an authentication scheme for keys, whereby the user will be prompted with one of those "Enter you name & password..." popups when a cgi script first requires it. This is done once per browser session, so the user will have to enter his info the first time he uses your forum (or any other application at dantom.com that requires authentication), but not afterwords. I'm hoping we can get the internal BYOND browser to automatically authenticate (since we already know the login info obviously), but that doesn't work just yet. [Edit] I should mention that once the user has been authenticated, client.key and mob.key will automatically be set to the appropriate key name. We'll provide a "hook" on your end to access this scheme. It shouldn't be too difficult. If you want the authentication to persist between sessions, you can always do it manually be generating a "cookie" that is stored on the user's client (and usually has some sort of encrypted id as to who the user is). You could generate this from his key after he has authenticated for the first time, and check for it thereafter. Cookies may expire after a certain period of time. The forum here uses cookies, and we can probably provide some provisions to do so if they don't already exist in one of the dm libs. A usability item: One thing I've noticed is that while the server has a way to know that a file is a CGI program (becase the admin registers the extension with it), the browser does not seem to be aware of this. So it tends to redisplay the page it already has rather than getting an update. I found myself having to force a refresh while testing things out. Is there any way around this? Good question! I'll let Dan answer it! | |
On 11/1/00 11:14 am Tom H. wrote:
Web pages hosted at dantom.com have access to an authentication scheme for keys, whereby the user will be prompted with one of those "Enter you name & password..." popups when a cgi script first requires it. This is done once per browser session, so the user will have to enter his info the first time he uses your forum (or any other application at dantom.com that requires authentication), but not afterwords...I should mention that once the user has been authenticated, client.key and mob.key will automatically be set to the appropriate key name. I love you guys! This is so incredibly cool. In all seriousness, as a complete sidelines to the purpose of BYOND you have created something that could be advertised purely as a great way to create web apps. The only thing missing at this point is robust communication with a database from multiple processes...wonder if we could do that part with Python or Perl? (Python would be nice cause then I would learn it and because it is startingly similar to DM.) Anyway I don't quite know what I'm going to do with all this yet...but the brain is churning. | |
On some day at some time, Silly Ol' Tom wrote:
but not afterwords. This must be the sister typo to "Forward". ;-) | |
I am totally clueless here... I don't know what you guys are talking about, and I don't even know enough to ask helpful questions. You are somehow using BYOND to make web pages that can be accessed without byond software?
Z | |
On 11/1/00 1:45 pm Zilal wrote:
I am totally clueless here... I don't know what you guys are talking about, and I don't even know enough to ask helpful questions. You are somehow using BYOND to make web pages that can be accessed without byond software? I'm fairly stumped too. I'm trying to see what the use would be. | |
On 11/1/00 1:46 pm Spuzzum wrote:
On 11/1/00 1:45 pm Zilal wrote: Oh ho ho... First off, yes, this is BYOND .dmb files creating web pages. Dan's example is a regular BYOND game world .dmb file, which you interact with from the web. Try it! I'm fairly stumped too. I'm trying to see what the use would be. Ah, once you start seeing what it's about, the question will be: what CAN'T you do with it? Cerulea could serve up web pages about what's going on in the world right this moment...so you can see what's up from your browser at work/school even though you can't get into the game. Further, Z could administrate Cerulea through the web from any computer in the world -- she could have private web pages that let her unleash storms on her hapless players whenever she felt like it. She could even send messages to individual players and get messages back from them. A forum available in game can also be available on the web...the screenshot site we're doing for DragonSnot will be viewable in-game or from the web, and you'll be able to do searches and stuff. And that's just game-related stuff...you could also put together a commercial site very easily if you wanted, nothing to do with games at all. In that case, you do it because DM is so much easier to program in than other languages. The DDT website will probably be totally dynamic using BYOND...when you access it, all the text and menus will be customized according to which DDT games you play and the like. Oh don't get me started! This is gonna be HUGE! [edit] Hmm...something I should make clear: All this mumbo-jumbo that Dantom and I are talking back and forth probably makes this sound complicated. That stuff is grungy technology details that you won't have to worry about. Let's keep it simple...you can have a fully dynamic web page with this much code: CGI Topic(href) usr << "The current time in BYOND land is [dd_time()]." | |
Let's keep it simple...you can have a fully dynamic web page with this much code: But... I don't understand. Is CGI some new kind of object? What exactly gets passed into Topic()? What do you do with this code... does it have to be in a .dmb that's online? How do you direct people to the web page it creates? Z | |
But... I don't understand. I know what it is for, but I still can't see how reporting my stuff to a web page would be of any use; if I want to do something, I'll do it in-game, and if I want someone to check out what's going on, they should join the game itself. Is CGI some new kind of object? It's defined in the CGI.dm library. What exactly gets passed into Topic()? Not sure... What do you do with this code... does it have to be in a .dmb that's online? Yep. You copy the .dmb file to a DM-CGI Ready web server, and then run that like any ordinary webpage link: [a href="http://polaris.dreamhost.com/home/spuzzum/ notadmbyet.dmb"]Click here![/a] Addressing all of those, CGI is a new feature of the Polaris server. Download the html forms library from the hub or InfoCenter, and you get the CGI library with it. Basically, it is a DM replacement for much more obfuscated (I love that word!) CGI, internet language of the damned. That's about all I can really muster about it without having a chance to befuddle with it at home. Oh, well, I get out of school in 20 minutes... what do you know. | |
On 11/1/00 2:12 pm Zilal wrote:
But... I don't understand. Is CGI some new kind of object? Yes...if you download the CGI library, then CGI is just an object that can be called like any other object, and it's an object that knows how to talk to the web. What exactly gets passed into Topic()? Here is how CGI-related URLs work (no matter what system you are using): First there is the base of the URL, which points to the CGI program (it's just like any URL that points to a page): http://dan.byond.com/demo/hello_cgi.dmb That's Dan's working example. When you click on that link, the hello_cgi.dmb file gets called with no extra info -- which means that the href passed to CGI.Topic() will have no content. In that case Dan sends back a form so you can fill in your name and press the Submit button. When you press Submit, it's actually just called the same .dmb file again, but now with some extra info: http://dan.byond.com/demo/hello_cgi.dmb/Form/Hello?name=guest Again that's a working link. The extra info is what comes after the base URL...so in this case it is "/Form/Hello?name=guest". That text is passed into CGI.Topic(). When Dan's form code sees "name=guest", it knows that the name you entered is 'guest'. The form code will handle forms automatically for you...and/or you can respond to the extra info in any way you choose. The way to think about this is: It's just like any code you would do for the browser in BYOND. Exactly the same thing is happening: you are creating links that pass info to a Topic() function. What do you do with this code... does it have to be in a .dmb that's online? The .dmb needs to be in the web server directory of a machine with a web server. You can set up your own (Apache is a free web server that is quite easy to set up on a Windows machine) but you won't want to. Just wait until the new server accounts are available. At that point, you just drop a .dmb file into your account's web directory. How do you direct people to the web page it creates? It's just a URL. Again, Dan's working example: http://dan.byond.com/demo/hello_cgi.dmb So when you have a Polaris account, it will be something like: http://zilal.byond.com/Cerulea/daily_world_status.dmb Feel free to ask all the questions you want...you'll only see that it gets simpler the more you understand. | |
On 11/1/00 3:01 pm Spuzzum wrote:
I know what it is for, but I still can't see how reporting my stuff to a web page would be of any use; if I want to do something, I'll do it in-game, and if I want someone to check out what's going on, they should join the game itself. Ah a chance for a Deadron prediction: Within one month (two max!) the Spuzzmeister will have done some web-based game functionality and will have plans for more. Within three months he'll never know how he did a game without it. Not only will the CGI functionality be central to many games, but it might be the major factor that allows us to overcome the "but I have to download BYOND to run this and I don't want to" factor. We'll be able to introduce people to the games -- even let them interact with them -- before they ever need to download anything. | |
Ah a chance for a Deadron prediction: Well, here's a deal. You'll save your predictions until after I've looked at the functionality in detail, and I'll save my complaints about it until then. Sound all right? =) | |
On 11/1/00 1:55 pm Deadron wrote:
Further, Z could administrate Cerulea through the web from any computer in the world -- she could have private web pages that let her unleash storms on her hapless players whenever she felt like it. She could even send messages to individual players and get messages back from them. I was just thinking about the fact that with a Palm VII you can access the web from wherever you happen to be standing. Then I had this image of Z sitting at a bus stop, bent over her Pilot, cackling as she releases plagues upon her players. Hmm maybe this is too much power for mere mortals. | |
On 11/1/00 3:31 pm Deadron wrote:
We'll be able to introduce people to the games -- even let them interact with them -- before they ever need to download anything. Wasn't a java BYOND proposed way back when for people with macs? Is this leading us to it? Will there one day be a window with scrolling text and a type-in box through which people can access Cerulea from a web page? Z | |
On 11/1/00 6:16 pm Deadron wrote:
I was just thinking about the fact that with a Palm VII you can access the web from wherever you happen to be standing. Then I had this image of Z sitting at a bus stop, bent over her Pilot, cackling as she releases plagues upon her players. Yesss... all two of them!! Z | |
Glad you like it! I almost went the wrong route and made the entry point into the CGI program world.Topic() or something like that. That seemed logical, since CGI programs are single-user.
But at the last minute, I hit on this notion of making the web user appear like a regular byond client, with a mob, and the whole works. It worked out very beautifully, because with only a tiny alteration, the whole html/form.dm library works in either BYOND or CGI mode.
Just to whet everyone's appetite, this little snippet is a fully functioning CGI form web page:
#include "html/CGI.dm"
#include "html/form.dm"
CGI/default_form = /Form/Hello
Form/Hello
form_title = "BYOND CGI!"
var
name
ProcessForm()
usr << "Hello, [name]!"
Initialize()
name = usr.name
As proof, click here!
And just in case, you didn't realize it, you don't have to build up the whole document in a string before outputting anything. If you want you can just transmit each piece to usr as you go along.
Oops. Good point. I have fixed that.
--Dan