[MUD-Dev] Embedded languages, object persistance... ack.

[Jay Carlson]

[...the moo apologist wakes...]

"Joe Kingry" <jkingry at uwaterloo.ca> writes on Wednesday, December 29, 1999
4:03 AM:


> I mean, I know what the goals in general are. Persistance. You have a
house
> say in some place in the world. It get's damaged, it stays damaged until
it
> is repaird. So persistence is done through some kind of database, or
> multiple databases broken up to distribute categories/workload.

Geez, this has been around in the Tiny family and DGD for years.

The big lose of persistence is that it's harder to get things back to a
known state if your code screws up.  For instance, some MOO projects I've
worked on have had fsck-like state checkers that would attempt to clean up
broken object state and half-broken links.  By forcing programmers to
explicitly manage state, you force them to spend some time thinking about
these kinds of things.  OTOH, when you're prototyping it's not something you
care much about.

> I want a mud server on which I can change the code online of say a skill,
a
> spell or something else. I understand that this is the purpose of having
an
> embedded language that runs "on top of" the mud's driver. i.e. MUF for
MUQ,
> Python for AR3 etc.  So in general I know this code is to be compiled
since
> you don't want to be executing "scripts", but is this code an object? and
> then is the byte-code stored? ack.. I'm confused.

Slightly offtopic: there's an interesting terminology/concept confusion
common in MUD object design discussions.  Usually when we're talking about
mud objects, we're thinking of things like rooms, swords, NPCs, etc.  In
languages like Smalltalk, everything is an object, even a method.  I've seen
many people (especially myself) going down ratholes where you can pick up
integers or method definitions, or fail to design using the programming
language objects to build when difficult to figure out a VR behavior for an
abstract concept.

> All I want in a mud server is this:
>
> -doesn't have every object in memory, only when needed, otherwise on file.

MOO trivially satisfies this; after all, there are many fine lines of code
in the kernel to do it, so why duplicate?

> -doesn't require me to learn it's "own custom embedded language", this one
> really gets to me
> -somehow allows for security and access levels while coding

As far as I know, there are no mainstream languages for dynamic persistent
programming environments that do anything plausible with multi-author
security.  So I think you lose on this.

Explicit representation of authorship and authority in dynamic languages is
pretty interesting.  Doug Orleans is working on it.

> -somehow allows for an event type system

Any of the full-out programmable servers will give you many different
options for how you want to code your own personal event system. :-)

> -allows code to be contained in packages and has appropriate management
> features. Ie. I can write the code offline in a file and then upload the
> file to the server

This requirement is difficult when combined goal of a persistent
environment.  In many cases it doesn't make sense to be hacking on objects
out of context; consider adding and removing object properties.  There has
to be a pretty full set of synchronization logic for this to really work the
Right Way.

> -will allow for http access to the database

JHM was the first mud web server, and there are n different competing MOO
web application frameworks....

> An added bonus would be, but hardly nessesary:
> -driver ported to both Win32 platform and *nix platforms and database is
> independent of platform.

Mostly true of MOO, modulo crypt() issues.

Jay




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev