# New MOO Maintainer: Me

Zachary DeAquila (zachary@zachs.place.org)
Mon, 22 Jul 1996 15:12:20 PDT

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

    [A Word fFrom The Server Maintainer partially deleted]
    >That's all very vague and abstract, so let me get more concrete, and
    >list a few of my long-time and more recent goals, the grand and the
    >petty mixed in no particular order:
    >
    >  Database-accessible features:
    >
    >  * Dictionaries (aka hash tables):  Data structures that map a set of
    >    "keys" onto a set of values.  We can do this right now with
    >    association lists, but they're inefficient and in some ways not
    >    very pretty.  Also, they make it easier to do:

    Sounds good.

    >  * User-defined aggregate data types (aka lightweight objects, aka
    >    garbage-collected objects, aka "frobs").  Rather than go into
    >    this subject here, I'll refer you to
    >      http://www.cold.org/ColdC/Structure/types.html#frob
    >    for the ColdC (formerly ColdMUD) version; also see the
    >    discussion of method call, in the "expressions" section.
    >    MOO frobs will not be exactly like ColdC frobs, even assuming
    >    I do implement them, but they'll be close.  I expect we'll
    >    discuss this more as time goes by.

    Yah!  Lightweight objects are cool...

    >  * (I used to think that, along with frobs, we should be able to
    >    define methods on the built-in data types, so that _all_ data
    >    can become "active", knowing how to respond to certain verb calls,
    >    and so on.  I'm less convinced of that now, but it's still a
    >    possibility.)

    To me, this sounds like a win, and if nothing else will clarify the charter
    of $list_utils, $string_utils, etc. as they become {1,2,3}:tostring() and
    "{1,2,3}":tolist(), etc.

    >  * "Handle" data types.  Often, particularly in creating server
    >    extensions, you want a value that "stands in" for some larger
    >    structure.  For example, a file-system access extension
    >    (designed differently from FUP) might want to let people open
    >    and make persistent reference to file streams.  Sometimes
    >    integers will suffice for this; but I claim you want a type
    >    that doesn't require explicit deallocation (e.g., file_close()),
    >    since MOO code generally can't be relied upon to clean up after
    >    itself.

    Hrm. I'm not sure what's included here that can't be covered by
    frobs (above) but it sounds reasonable...

    >  Server features:
    >
    >  * Mix-and-match extensions.  It should be possible to combine
    >    server extensions with a minimum of effort.  We're getting
    >    there--extensions.c alone is a great improvement--but I think
    >    there's more to do.  For example, I'd like to pursue the ideas
    >    for extension package format that came up in March on MOO-Cows.
    >    ThwartedEfforts's message
    >      http://forney.scinc.com/~abakun/moomail/96.03/msg00342.html
    >    is a good place to start reading that thread.

    Customizability is always good.

    >  * It should be easier to revert to a "previous" version of the
    >    server, or at least to one without a given server extension.
    >    call_function() and the practice of automatically converting
    >    unknown function calls helps with this.  I have ideas for
    >    rolling back from extensions that do more than add new functions.

    Version control is good.

    >  * Dynamic loading (on platforms that support it).  I'm not sure
    >    yet whether it will be possible to actually load modules while
    >    the server is running, but it will at least be possible to add
    >    new extensions to load on startup, without recompiling your
    >    whole server.  (I know there's at least one prototype
    >    implementation of this already.)

    Less downtime is good; on that note, one of the reasons many people
    like MOO over things like diku is that you dont have to recompile the
    whole dang server every time you make a change to the db... this extends
    the idea to the server level...

    >Among the ideas from Pavel's 1.8.0 features list that didn't
    >get implemented, the ones that appeal to me most are verbdefs
    >(persistent handles for verbs)

    I don't remember this one, but it sounds like a good idea instead of
    depending on the verbname for such things.

    >and foo:bar/call_proc (splitting verb
    >lookup and call into two separate actions).

    this sounds like a good idea - tentative steps in that direction were
    taken with the #0:do_command hook, but something a bit more flexible
    and less tedious (not to mention faster) would be better.  I've always
    favored regexp-matching parsing, myself.

    >A lot of these are fairly tentative, and maybe unnecessary or unwise;
    >but they're things _I_ think the server could use, provided a good
    >deal of good design is done on them.
    >
    >So now we get to the question, which is one you're probably demanding
    >by this point:  What do _you_ all want from the server?  There are a
    >few features that I know are commonly requested but that are
    >conspicuously absent from my list; I'll let you name them.  I bet
    >there are other things you want that I don't even know about.

    Well, diskbasing would be a Good Thing, IMHO.  Object granularity
    at least, property/verb granularity would be better (ie. dont load a
    property into memory unless it's actually in use - the memory savings in
    old mail alone would be astronomical)  NOTE: This may extend LambaMOO's
    lifetime quite a bit, since it's pushing hardware limits as we speak.

    Also, though this may not be in the charter of the Server Maintainer, a
    standard sort of MOO-code module system would be good...

     --Zachary