[Prev][Next][Index][Thread]

# [SERVER] LambdaMOO 1.8.x feature wishlist

- Date: Mon, 11 Nov 1996 02:50:56 PST
- From:
- 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

Follow-Ups:

- 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

Home | Subject Index | Thread Index