[SERVER] LambdaMOO 1.8.x feature wishlist

• Date: Mon, 11 Nov 1996 02:50:56 PST
• From:
  Michael Brundage <brundage@laurel.ipac.caltech.edu>
• Content-Type: TEXT/PLAIN; charset=US-ASCII

There have been lots of posts on features which some would like added to 
the next (or some other future) version of the MOO, but I haven't really 
read about any at the level of the internal virtual machine.

Some improvements I would like to see implemented:

(1) Security.

     Limit string and list lengths to prevent malicious programmers
     (or unfortunate accidents) from bringing down any MOO currently in 
     existence.

(2) Optimizations.

     Since I've not yet examined the VM at any length, it's harder for me 
     to accurately comment on these, but a few obvious ones (which, 
     since they're obvious, may already be done) are:
   - differentiate between constant and mutable strings (String and 
     StringBuffer in Java)
   - differentiate between property fetches and stores so that 
     property values could be cached if known to not be altered during
     task execution. This would obviate the need for things like
       ou = $object_utils; for each in ([1..max_object()]) 
       player:tell(ou:ancestors(each)); endfor
   - provide a mechanism for just-in-time compilation into native
     object code.  I wouldn't expect this to be fully implemented for
     any given architecture, but it would allow motivated individuals
     an opportunity to add support for it without each such person
     rewriting it themselves.

(3) Customizable exceptions/error handling.

    Okay, this is a server/db interface issue, but it comes into play
    with the VM.  Currently, the server says, "such and such error
    results in such and such error value."  For example, read() raises
    E_INVARG when a "connection is closed while a task is waiting for 
    input but before any lines of input are received").  Now 
    that we can raise arbitrary values as exceptions, it is no longer 
    necessary to have somewhat arcane mappings from these errors to the 
    limited set of builtin error values.  Instead, use property values
    on $exception (or if you don't like creating a new server-assumed
    object, maybe use $server_options.exception_*) to describe the 
    exceptions to be raised.  E.g., $exception.divide_by_zero
    To keep the overhead down, you could require these properties to 
    always exist in the database, and then those who don't want to 
    customize them could just leave them at their current default values.



Comments? Other ideas?


Cheers,

michael
brundage@ipac.caltech.edu

• Re: [SERVER] LambdaMOO 1.8.x feature wishlist
• From: Amy Bruckman <asb@media.mit.edu>
• Re: [SERVER] LambdaMOO 1.8.x feature wishlist
• From: Christopher Unkel <cunkel@us.itd.umich.edu>
• Re: [SERVER] LambdaMOO 1.8.x feature wishlist
• From: Erik Ostrom <eostrom@research.att.com>

• Prev: Re: [SERVER] JIT compilation of MOO code
• Next: Re: [SERVER] LambdaMOO 1.8.x feature wishlist
• Index: MOO-cows
• Thread: MOO-cows