Subject: ideas for the next big release of MOO server.

From: [email-masked] (Chad Wilson)
Date: Tue, 18 May 1993 15:02:52 -0700

I have a short list of items i would like to see in the next BIG release
of the MOO server (2.0?).

Disk-based
----------
Okay, i'm not the only one.  I'm not the first to suggest it.  I just
wanted to reiterate it. 8)

Server-level $recycler
----------------------
Instead of using MOO code to implement the $recycler, put it at the server
level, where it would be much more efficient (and quicker).
no more worries of misinformed programmers using recycle(), it would be okay.
(This might screw up character generation, since it is the only thing that
doesn't use the $recycler in the new versions of the core.)

Case statment
-------------
An addition to MOO code.

BASIC even offers it, now.  no more
if...elseif..elseif..elseif..else...endif structure messing up nice tidy code.

That's all i can come up with as i'm very tired right now.

(My 5 cents worth.  I deem myself more important than 2 cents.)

---

From: [email-masked] (H. Peter Anvin N9ITP)
Date: Tue, 18 May 1993 19:53:09 -0700

> Server-level $recycler

Also, it would be nice to have a compile-time option of letting only
wizard-owned verbs call create() and recycle(), since some MOOs may
wish to implement independent ownership audit systems.

	/hpa

-- 
INTERNET:  [email-masked]    FINGER:    [email-masked]
BITNET:    HPA@NUACC      IBM MAIL:  36073 at IBMX400
HAM RADIO: N9ITP, SM4TKN  NeXTMAIL:  [email-masked]
"Kissing a smoker is like licking an ashtray."  -- R. Heinlein

---

From: Greg Hudson <[email-masked]>
Date: Tue, 18 May 1993 19:09:16 -0700

> Disk-based

This actually isn't terribly difficult to do.  There are existing
network layers (I'm thinking of Marcus Ranum's in particular) which
would allow MOO to be disk-based with few modifications.  The trick is
doing it well; if you're not careful, various things can cause most of
the database to be loaded in--and processes never give memory back to
the operating system.

> Server-level $recycler

You can't just up and decide to move database code into the server,
whether or not you'd like it to be faster.  Although I'm not as
familiar with the Lambda core as I should be, I would expect that the
recycler knows a lot more about the database than the server does.
For flexibility reasons, the server should probably know as little
about the database as possible; in my opinion, MOO knows too much as
it is.  I may be misunderstanding, though; if the recycler just
recycles object numbers, then it doesn't really matter whether it's in
the core or in the server.

> Case statement

I do like this one, although I havne't implemented anything like it in
Coldmud.  I'm not entirely sure how I'd like to see a case statement
structured, or what the best way of implementing it.

--GBH

P.S. For those who keep wondering what I'm talking about when I keep
mentioning Coldmud, it's a fairly generic multi-user object-oriented
database server and progrmaming language, borrowing a lot of ideas
from Coolmud.  I have a discussion list set up for it at
[email-masked]; send to [email-masked] to
subscribe.  Discussion is not archived and doesn't happen all that
often, since I haven't released a testing version yet.  I expect to
have a testing version ready sometime in early June.