# on-the-fly guest creation

dave@ipac.caltech.edu (dave@ipac.caltech.edu)
Fri, 25 Aug 1995 15:02:34 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    On the fly creation of guests sounds like an interesting idea and I don't
    want to poo-poo it.  On the contrary, it is a much more OO way to handle
    guests, which ought to be different objects when used by different people.

    Here's a way to do it (stolen from how we do web connections).  The basic
    idea is you want #0:do_login_command to return the object number of a newly
    created guest object.  The server will then hook that up to the actual
    network connection behind the scenes.  How the server causes connections to
    be made to player objects is documented in the programmer's manual and in
    the installation notes.

    1 -- Modify $login:connect so if a guest is connecting it returns the object
         number of a newly created guest object:

              if the connection is as a guest
                create new guest object
                return objnum of new guest object
              else
               do the usual thing
              endif

         Before modifying this verb @copy $login:connect to $login:connect(old)
         in case you need to restore it.  Then if you goof you can always log
         back in using a line like

              connect(old) Me MyPassword

         Its a good idea to keep original copies of important core verbs lying
         around in case you ever need to go back to them.

    2 -- creating the new guest object is easy

              new_guest = create($guest,$hacker);

         when it is created, its initialize verb is run, code that to do any
         special setup you want.  For example, you could assign it a color name
         here (and remove the name from a name depository).

    3 -- Now when a connection is made as guest, a new guest object is formed
         and handed to the user.  At the time the hand-off takes place, the
         new guest's confunc verb is run.  Code in there any special stuff you
         want related to connecting.  For example, you may want to maintain a
         list of currently connected guests.

    4 -- When the guest disconnects, its disfunc is run.  Code this to reflect
         any actions you want to take place when a guest disconnects (in our
         example, you would remove it from the currently connected guest list).

    5 -- As part of the disfunc (actually it is probably best to fork it off of
         the disfunc) recycle the guest object so you don't get a kazillion
         defunct guests rotting in $limbo.  When it is recycled, its recycle verb
         is run.  Code this to do anything dealing with destroying a guest object,
         in this example you would return its name to the name depository.

    6 -- For peace of mind, you may want to put some code in $guest:disfunc that
         disallows recycling $guest itself, ie:

              guest disfunc verb code
              if (this != $guest)
                fork(0)
                  recycle(this);
                endfork
              endif

         This is just in case somewiz gets silly and succeeds in logging in as
         $guest, forgetting that disconnecting will destroy the object.

    You may want to think a little bit about object numbers of guests.  If you
    do create guests on the fly you can use the recycler to give you old used
    object numbers.  In this case, if those objnums are already living as property
    values etc in the database, strange results could happen from time to time.
    On the other hand, if you use the built-in create to get a new object number,
    you will (depending on your guest usage) build up a lot of empty object
    slots and drive max_object() through the roof.  This would, though, be a
    cleaner approach and is what is usually done with ordinary users (players).

    Hope this helps.  We use this method to handle web connections to our moo,
    except instead of making children of $guest, we make children of the new
    player class $web_user (and instead of connect, the verb to login is GET/POST).

    On the fly object creation is a nice method for many things, it's too bad to
    some extent that many programmers are faced with object or byte quota and
    have not turned their attention to the possibilities it enables.