# New MOO Maintainer: Me

RICHARD JACOB CONNAMACHER (phantom@sfsu.edu)
Mon, 22 Jul 1996 22:19:03 PDT

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

    Congradulations!  You sound like you've got the right idea on how to
    improve the MOO server, and I'm confident that you'll be an asset to us
    all.  Initial kiss-up spree over, here's my list for what I want in a MOO
    server (Some of this may have already been mentioned):

    * Hash tables are good.  (You already mentioned this)
    * Non-overridable verbs are good, perhaps a 'n' permission for verbs
    makes it nonoverridable?
    * Make binary strings a separate data type.  Let me give my reasons for
    that:
      I noticed a problem when I was programming the 1.8.0-friendly upgrade
    to BayWeb.  What I wanted to do is allow for extended character sets,
    like Latin1, using binary strings to represent the high range
    characters.  The problem is, when is $http to know whether the
    string is a binary string (ie extended) or whether it is a standard
    string (ie not extended)?  It is impossible to distinguish them from one
    another.  I could make it assume the output to be ascii unless other
    specified, but that complicates things that should, IMHO, be kept
    simple.  I'd like to see a BIN data type that allows for binary strings,
    and keep the STR data type as it was pre-1.8.0.

    * Modular extensions to the server.  By this I mean set up FUP so that,
    instead of calling fileversion(), you would call fup::version().  This
    will keep the number of builtin functions from getting overcrowded, and
    will overall simplify things I think.

    * Profilers!  'nuff said. :-)

    Now, about disk basing.  I used to think that full disk basing is the way of
    the future for MOO.  Now I'm not so sure.  I'm no experienced UNIX
    hacker, but unless I'm mistaken, most implimentations of UNIX already
    come with a super effecient disk basing system already built directly
    into the memory manager - it's called swap.  I can see some benefits from
    doing the disk basing implicitly:  it makes checkpointing much easier on
    the machine, and it allows some data to survive the inevitable
    database-corrupting crash.  Both of these can be done implicitly from
    in-database with FUP, and I'm working on a $filesystem project to make
    using it easier.  (I actually started working on one about a year ago,
    but set it aside because of school considerations.  I just restarted it
    again last week and hope to have a working version finished within the
    month.)  So full diskbasing, to me, is not really a top priority.

    Phantom