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

# Re: New MOO Maintainer: Me

- Date: Mon, 22 Jul 1996 13:41:12 PDT
- From:
- Fake-Sender: pavel@parc.xerox.com

    Christopher Scott Delaney wrote, on MOO-Cows:
    > So, when do we get to hear from the new maintainer?

    Yes, I was starting to wonder that too.  Sorry, everyone, that I've taken
    so long to post a hello.  And please, bear with me a bit longer;
    taking over the MOO server is a big transition, and it will take me a
    while to get fully organized and capable of handling all of it at once.

    On that subject, I'd like to express my admiration for Pavel, who has
    been astonishingly organized and capable at this for the last six or
    so years, and my gratitude to him for developing this software and for
    giving me the opportunity to try to live up to that.

    Now, on to being heard from:
    > I'd like to know what kinds of plans he has for the server in the future
    > (not necessarily the near future ;) etc.

    Me too!  So here's what I'd like to do:  Make a statement, ask a question.
    I'm liable to be long-winded, so if you like, skip to the question down
    below.

    First, let me tell you about my biases.  My primary interest in the
    development of the MOO server is to make it easier and less
    problematic for _other_ people to extend it.  As an early MOO hacker,
    I got bitten both by the number of things that couldn't be done
    cleanly within the database, and by the difficulties of maintaining
    server modifications without being The Server Maintainer.  So I always
    wanted it to be easier to do these things, so I could pursue my pet
    projects.

    Now, of course, I _am_ The Server Maintainer, but it turns out it's
    still to my advantage for the server to be independently extensible.  For
    one thing, I still have my own pet projects, that require changes it
    makes no sense to inflict on the rest of you.  On the other hand,
    other people have their own projects, and the more we can work on
    them independently, the less _I_ have to work on keeping everyone
    in sync.

    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:

      * 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.

      * (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.)

      * "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.

      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.

      * 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.

      * 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.)

    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) and foo:bar/call_proc (splitting verb
    lookup and call into two separate actions).  I don't consider those
    central, and I've got plenty on my plate already, but they give
    another idea of the sort of thing I'm interested in.  The features
    list is at
      http://forney.scinc.com/~abakun/moomail/94a/msg00261.html

    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.

    In addition, I'd like to get to know my users a little--at least, I'd
    like to be familiar with those of you who are running MOOs, and with
    the kinds of MOOs you're running.  I know only a few of you, and I know
    there's a lot out there.

    So, I'd like to get some discussion started on MOO-Cows--basically, I
    want a recurrence of the "wish list" thread we engage in every few
    months.  Tell me what you want from the server.  If you think it's
    interesting to others (and it probably is), post it to the list.  Even
    if all you want from the server is that it continue to work (an
    important feature!), feel free to drop me a line introducing yourself
    and your MOO.

    That's all I have to say for the moment.  I'll start replying now to
    some of the bug-report mail that's come through since I was announced,
    but if there's anything that got posted since the last server revision
    but before Pavel's retirement, I might have missed it; please, if you
    sent in anything like that, send it to me in private mail.

    Thanks
    --Erik

    P.S.  Although Pavel announced me as eostrom@research.att.com, a
    better address for reaching me, for now, is eostrom@ccs.neu.edu.
    Thanks for your patience.

Follow-Ups:

- Re: New MOO Maintainer: Me

- From: Richard Godard <janus@cam.org>

- Re: New MOO Maintainer: Me

- From: Zachary DeAquila <zachary@zachs.place.org>

- Prev: Re: New MOO Maintainer: Erik Ostrom
- Next: Re: New MOO Maintainer: Me
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index