MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: New MOO Maintainer: Me


[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
Follow-Ups: References:
Home | Subject Index | Thread Index