[MUD-Dev] Re: Bruce Sterling on Virtual Community goals

[Bruce]

Good day all,

I've been wanting to reply to something in this thread for a while now, but
was (am?) a bit afraid of sounding too evangelistic.  I'm with the Cold
Project and head up the driver development over there.

On Tuesday, 20 Oct 1998, Marc Hernandez wrote:

>On Wed, 21 Oct 1998, Joel Kelso wrote:

>}What specifications are people interested in ?  A personal feature list
for a
>}MUD, in
>}rough order of priority:
>
>}    *    persistent object store and network accessability (obviously)
>


We've got this.  We have a disk-based database, employing caches for keeping
currently (and recently) used objects in memory.  This cache is resizeable
at startup time, but I'd like to see it be resizeable at runtime.  All of
our networking code is done in-DB (the higher level part of the system,
written in ColdC, not part of the driver).

>}    *    text-based network interface for a "player" class of user (at
least)
>
> Im personally interested in it as a base for a graphical mud.
>Thus it would be nice if this type of functionality could be at least
>#ifdefed out.  Also 'player' might mean very different things to different
>people.


Isn't this a higher-level issue belonging more with the design of the system
built upon the base?  Although, I am used to a more minimal base with as
much left out of it as possible.

>}    *    programming language and tools for building large, complex and
>}        dynamic virtual worlds


We've got this.  Cold is currently used by The Eternal City, a commercial
game with a very large, complex, dynamic virtual world.  It is also used for
things totally un-related to virtual worlds.  It's also the system behind
HoloTrek, www.holo.org.

> Hmmm.  A default language should be provided but the VM doesnt
>need to know about it.


Right now, the language is fairly embedded into the system, but, within
limits, I'm not sure that this is necessary and that with some work, there
could be multiple languages on the same VM.  Alternatively, you could have m
ultiple VMs and flag which VM is used for which code on a method by method
basis, or object by object (or whatever).

>}    *    dynamic programming and world-building environment (ie ability to
>}        add and modify functionality without taking down server)

I'd view this as a given when you've brought an embedded language into the
system?


>}    *    ability to communicate objects between servers


This could be written at a higher level using the networking functionality
that the rest of the system uses.  People have done this in Cold.

>}    *    portable source code


We're fairly portable, running on Linux, FreeBSD, Solaris.  Soon we should
be running on HP-UX (configure issues), and thanks to a fellow list member,
our Win32 port will be up to date again soon.

>}    *    scalability onto future hardware
>}    *    distributed database/processing for multiple-machine servers


I'd love to write a full post or ten about distribution and why I don't
think it has to happen at the driver (VM) level, but, rather, can be an
feature of the DB/core built on top of the base system.  My personal plan is
to base my core around event channels, and to not limit them to just the
single server, but allow events to flow between servers, with all of that
code being written in the embedded language.  Of course, if the events are
specified well enough, who is to say that one couldn't write some sort of
event processor in Python, or Java, or C?  I haven't seen network extensions
for Intercal, so perhaps Intercal wouldn't be permissible.

>    *   Low level security (perhaps by 'process' or something)


We have the ability to see what object called the current method, what
object defined the method that called the current method, etc.  In ColdCore,
we have a fairly good security infrastructure built upon that.

Someone else has built a much more complicated security structure that is
much closer to that of MOO.

Some other interesting work:
ftp://publications.ai.mit.edu/ai-publications/1500-1999/AIM-1564.ps.Z (HTML
version at http://206.165.240.44/LispOS/secureos.htm)

> There is also the Cold project.  Im not sure about some of its
>features but it has or will have many of these.  Im also not sure about
>its license.


Our license fully permits commercial usage.  It is currently being used
commercially, and I've used it for some commercial work previously.

I feel that we have many of these features, although current development
plans on the driver include things like adding threading to the driver to
separate out some of the networking code and other pieces, adding ways to
analyze the runtime performance of the database caches, internationalization
support for the string datatype, support for IPv6, etc.

We don't do everything perfectly, in fact there are a number of things that
we could probably do better, but I think that Cold currently has many of the
features that are being discussed and has an appropriate license.

I have a number of topics relating to some of this that I want to bring up
on here in the future, but I really need to finish digging myself out from
underneath a big pile at work.

 - Bruce