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

Re: New MOO Maintainer: Me

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