Subject: A Newbie's First MOO Impressions

From: [email-masked]
Date: Fri, 23 Jul 1993 15:30:53 -0700

Hello, all!

	I thought I'd share my first impressions of the LambdaMOO server
and the LambdaCore database; hopefully, some of you will take the time to
correct my erroneous first thoughts.  Just so that you know from where I
speak, I come from MUSH-Land, where I got frustrated with the relatively
poor programmability available, and I've built the Lambda server/core
combination and have been playing aroud with it for about a week.

OK, so here's my first thoughts:

	(1) Documentation:  While the documentation of the server and the
LambdaCore database are much more extensive that the typical M* system,
the database's documentation seems woefully out of date.  I think this is
primarily due to the fact that:

	(2) The LambdaCore database provides too much functionality to be
really considered a *core* database.  Now, features are nice, of course,
but the excessive feature-ism makes it (a) hard to understand, (b) hard to
document, and (3) hard to administer.  Should things like Mr. Spell *really*
be considered part of a "core" system?  :-)

	The really "core" part of LambdaCore seems to me to be the way
it implements a subset of the Tiny* model: how "say", "look", and "move"
commands get performed.  All this stuff like the MOO Editors and the mail
system just muddy the core ideas.  Don't get me wrong: I think these are
great!  I just think that they might be best distributed as separate
"modules", if for no other reason than to support independent development.

	(3) I'd love to see some documentation on the file format of the
database.  I suppose I could probably figure out part of it from looking
at the "dump" code, but I'd rather not.  :-)  Primarily, I think this would
be useful for people who were writing their db's from scratch (a la
Minimal.db), and have screwed them up, or are trying to recover a corrupted
db.

And what comment would be complete without some clamoring for new features?
*grin*  Anyways, here's some initial thoughts on what I think could be
profitably added to the server:

	(1) Some way to read and write files on the server machine.  I'm
invisioning "open()", "read()", and "write()" file primitives, usable only
by wizards.  The big advantage would be for things like the Help databases.
On server start-up, they could read a text help file.  It would make main-
taining the help system much easier.  Personally, I'd much rather use Emacs
than the MOO Editor to write documentation. :-)

Well, that's about the extent of my initial comments.  I've got some other
ideas on the back burner, which I'll post about when I've had some more time
to experiment.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Jack Eifrig ([email-masked])       The Johns Hopkins University, C.S. Dept.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

---

From: Pavel Curtis <[email-masked]>
Date: Fri, 23 Jul 1993 16:18:27 -0700

> Date:	Fri, 23 Jul 1993 15:30:53 -0700
> From:	[email-masked]
> 
> the database's documentation seems woefully out of date.

Granted.  Given the distributed, multi-programmer nature of core DB
development, I decided some time ago that the only feasible way to get the core
documented was within the help system in the core itself.  This has worked out
better than before, in that many more things are documented at all, but not
well enough to make for reasonable documentation for newcomers.

What we need is for some volunteers to write more documentation where it's
needed and then to transfer that into the core DB so that further development
can try to keep it up to date...

> "modules", if for no other reason than to support independent development.

I would love to be able to do this, but it's harder than you think.  It's
actually quite a production and a fair amount of manual effort just to extract
the current definition of the core.  I shudder indeed to think of the effort
that would be required to regularly extract just a piece of it in some form
that was useful to other people.  Of course, this is mostly a language issue
and should get addressed at that level.

> Minimal.db), and have screwed them up, or are trying to recover a corrupted

I don't think that there's any reason under the sun for anyone to attempt to
hand-generate a MOO database.  There are essentially no decisions made in the
Minimal DB, so there shouldn't be any need to start from less than that.

As for trying to recover a corrupted database, I don't recommend even trying
it; it's a royal bitch even for someone like me who understands the code
deeply.

All that said, though, I certainly have no objection to documenting the current
format while making it clear that I feel no obligation to remain compatible
with it in future releases.  I'll put this on my list for the next release,
though I have to admit that I'm particularly motivated to give it a very high
priority there.

> than the MOO Editor to write documentation. :-)

There are, of course, serious security issues related to this, but I won't
belabor that point here.  As for using Emacs instead of the MOO editor, that's
entirely understandable; that's what I do all the time.  However, this is
unrelated to whether or not the text is in the database proper.  The version of
mud.el in parcftp.xerox.com:pub/MOO/clients supports this very nicely.  You
simply type
		@edit-options +local
to the MOO.  After that, any @notedit or @edit command will pop up a local
Emacs editing buffer with the current text of the property or verb.  You edit
locally, use C-c C-s to send the new text back to the server, and C-c C-] to
neatly throw away that local buffer.  I wrote the first version of this support
as one of the very first things I did for LambdaMOO because I couldn't imagine
actually trying to use any in-DB editor for it (though no such thing existed
then).

Keeping everything in the MOO DB means that it's accessible to and modifiable
by *all* of the wizards, not just the one(s) local to the server machine.

	Pavel

---

From: Greg Hudson <[email-masked]>
Date: Sat, 24 Jul 1993 08:42:00 -0700

I thought I might give some perspectives on these issues, since most
of these problems are solvable:

> Given the distributed, multi-programmer nature of core DB
> development, I decided some time ago that the only feasible way to
> get the core documented was within the help system in the core
> itself.

I think this is a concession to lack of communication.  To me, the
problem doesn't seem inherent to having multiple programmers who don't
talk to each other in real life--the problem seems to be that the
core, like so much other software in this world, has evolved rather
than been designed.

> There are, of course, serious security issues related to [open(),
> read(), write()], but I won't belabor that point here.

This has been an issue for me in Coldmud.  I was originally planning
to provide an admin-only system() primitive that would pass a line to
the shell.  It was pointed out to me that making such dangerous
primitives administrator-only isn't enough.  Although it should be
harder to hack administrator privileges under a well-written Coldmud
database than it is in MOO, it's conceivable, and you don't want
people to have access to your file system if they do this.

I have provided echo_file() and run_script() primitives.  The first
only echoes files from the 'text' subdirectory of the database
directory, while the second only runs scripts from the 'scripts'
directory.  A check for ../ sequences prevents backing up through the
file hierarchy, and I never go through the shell under any
circumstances.

I agree fully, however, that local editing is a much better solution
than storing help text outside the database.

> I don't think that there's any reason under the sun for anyone to
> attempt to hand-generate a MOO database.  There are essentially no
> decisions made in the Minimal DB, so there shouldn't be any need to
> start from less than that.

> As for trying to recover a corrupted database, I don't recommend
> even trying it; it's a royal bitch even for someone like me who
> understands the code deeply.

Coldmud makes this problem considerably easier by having a special
database format intended to be easily read and modified by both
machines and people.  I should elaborate:

Coldmud, being a disk-based mud, has a binary database format.  The
binary database is intended for fast retrieval of objects.  It stores
all the hash tables there, stores references to IDs by number, and
other gritty stuff.  Coldmud can start up using such a binary
database, making startup time very fast.

However, the binary database format is terribly unsatisfactory for
anything but normal operation.  If it becomes corrupted, fixing it is
essentially impossible, especially since the internal structure of an
object depends on the rest of the hierarchy.  You can't mail it around
without uuencoding it.  Binary databases will likely become invalid
whenever there is a new version of the server, because I'm likely to
want to change the internal structure of an object or method
frequently.  At the moment, the format is also byte-order dependent,
although that will change soon (mostly for my personal convenience,
since I'm using a distributed multi-architecture system).

So I also have a function which dumps a text database in terms of the
C-- language and a few simple commands ('object', 'method', and
'eval').  Because this format is completely in ASCII and relies on the
C-- compiler to translate the text representation of objects into
their internal form, you can freely mail it around, modify it by hand,
and use it with any version of the server which can read in the code.
Of course, at the current time I'm making lots of incompatible
language changes, so it doesn't help much, but after I settle down and
stop revamping the language semantics every version, it should be a
big help.  And of course, recovering a corrupt text database is a
matter of excising or repairing the objects which contain damaged
text.

Naturally, any core database shipped with the server will be
written--possibly by humans--in the text database format, perhaps
annotated.

And here's another place where it pays off:

> I would love to be able to do [packages], but it's harder than you
> think.

Because Coldmud object IDs will be names rather than numbers fairly
soon, it should be quite easy to do.  Naturally, packages might have
dependencies on (named) objects in other packages, but this is
inherent to the problem.

Now, how to distribute these packages?  You could do it with client
support, and that might be more convenient, but it's also possible to
simply copy the appropriate object descriptions from the text database
dump and paste them onto the end of another text database dump, and
they will show up in the new database.  This will, naturally,
overwrite any objects with the same names as the new objects, which
may or may not be what you want.

--GBH
(Yes, yes, I know, you're all tired of hearing about the Vapor Server
to End All Vapor Servers.  I'm making progress.)

---

From: [email-masked] (Erik Ostrom)
Date: Sat, 24 Jul 1993 11:31:22 -0700

it should be
   harder to hack administrator privileges under a well-written Coldmud
   database than it is in MOO

I presume you mean "it should be easier to write a Coldmud database in which
it is impossible to hack administrator privileges than it is to write a MOO
one" or something less awkwardly phrased.  Obviously, in a well-written MOO
database, it would be impossible to hack administrator privileges (uh, that
is, without cracking an administrator's password).

			     recovering a corrupt text database is a
   matter of excising or repairing the objects which contain damaged
   text.

This doesn't help you unless you're constantly saving the database in text
format (probably in addition to a binary copy), right?