a few (6) months ago, i had the opportunity to run a virtual server (MU*) on a
friend's machine.  since i'm a fleshy-headed mutant, i had all sorts of plans
about a demand-based economy fueling character-evolved self-rule, a graphical
system of coordinate-based movement, etc...

to do a lot of these things, i needed a server that didn't make assumptions
about how i wanted to set things up, the interface to the command line, the
structure of objects, etc...
i compiled and ran a few, but none had both a general enough interface/language
with the performance and support i wanted, so i decided to write my own.
i tried to strip out as many assumptions and restrictions to versatility as i
could, then insert back in general and powerful tools for developers to use.

this is the announcement of the version I.beta release of Interlude.
It's a (beta) complete package with lots of bells and whistles ... not
that these are the issue:  people use what's easiest for them, not what
is the most gimmick-laden.  the features are listed below for the interested.

i don't really have the desire (or time) to try to convert anyone who is happy
with what they use now ... the release of Interlude intentionally coincides
with the start of school, and therefore the arrival of new people who don't
know how things are _supposed_ to be done.
but i know there are a few who are interested in exploring the potentials of
the networked space.  the ambitious projects of the next few years are going
to take new tools that are simple enough for new people to grow into while
being powerful and general enough to allow for expert use efficiently.

anyone interested in helping to test, host, or develop for this next-
generation project is encouraged to contact me at the address below, or to
grab a copy of the server or docs from /pub on summit.stanford.edu


-david engberg
 snarflrd@leland.stanford.edu
 trauma(hound)? @ most places
 geppetto       @ a few places



-----------------------------------------------------------------------------

GEE-WHIZ FEATURES  :
=========================

source:
written entirely from scratch in gnu-portable C++ code, using the standard
g++ library included with the gnu distribution.  compiles 'out of the box'
on an IBM and Sun with properly configured g++.  most code is extremely OO
in style (with a couple of glaring exceptions) and should be easy to re-use,
maintain, etc...

Coda:
a new programming language that steals liberally and
inconsistently from languages like Dylan and Scheme.  Since i've read Church's
hypothesis, i won't claim that it can do _MORE_ than other languages, but
i WILL posit that it is suitable for producing powerful code quickly, with
(IMHO) a more friendly learning curve than traditional Pascal-ish languages.

versatile type system:
the central feature of Coda is that the concept of 'type' for data
is separate from the notion of storage.  this allows me to have the traditional
data types (NUMBER, REAL, STRING, LIST, ERROR) along with:
SYMBOL - these can be used as both variable names and independent data that
         can be passed around as arguments, return values, etc.
METHOD - programs are just another form of data to be saved into variables,
         passed to other methods, compiled 'on the fly,' etc...
USER   - programmers can construct OO user-defind datatypes by grouping a
         set of methods together on an object, then creating values of that
         type.  these values can only be used by calling their protected
         methods, so abstraction through data/function encapsulation is
	 now available in an MU* language.

'true' object orientation:
each object is made up of a set of symbols defined on that object, a list
of command-to-symbol mappings to speed parsing, and a list of the parents of
that object.  any behavior not defined by an object can be inherited from its
parents.  all data on objects is inherantly private.  objects only respond to
messages (calls) from other objects.  this allows...

multiple inheritance:
objects have multiple parents in the OO paradigm.  there has been a LOT of
argument over the value of this, but _many_ people have found it useful to
define objects in terms of what combination of other things they behave like.

bit-/flag-free database:
objects aren't burdened down with ugly, memory-eating flags to control who
can read/write/execute certain actions on the object.  since objects themselves
are free to define the results of message calls, they can internally check
all the things that flags used to.

override control:
to allow for guaranteed behavior by objects in the database, no object can
save to method names starting with the '~' symbol if any of their parents
define that symbol.  this allows for a clean safety mechanism to prevent
errant programmers from doing horrible things with the nice, clean language...
just define certain ~-methods on the core objects that allow administrators
to seize control whenever needed.

disk-resident database:
objects are only loaded from disk when they are accessed, and they are
released from memory when not in use.  this should remove memory as the
primary limitation on how large your universe can grow, since you will
only be limited by (cheaper) disk space.

dynamic object persistence:
objects feature collections of data that remain constant between crashes,
reboots, etc... if you have created an object that has been changed by the
environment, those changes will still be there after a reboot.  objects
exist in a database, not in text files that need to be edited and compiled
to make changes.

multi-threading:
the server simulates multitasking by keeping a process store and allowing
each active process a small number of ticks on each pass.  Many people
think this sort of feature in an OS/server is groovy.  the jury's still out,
but it sure SOUNDS cool, no?  ;-)

filetext, run-script:
these built-in functions allow the site admin to set up directories full of
text files and Unix executables which can be read and run from within the
server environment.

parsing within the database:
to try to reduce the number of assumptions the server makes while still
maintaining as much performance as neccessary, parsing has been moved into
the database to allow the command-line to be interpreted without relying
on any specific format imprinted into the server by the writer.  this
means that any sequence of characters can be analyzed within the Coda
language to determine the user's course of action.  Tiny-style and Moo-style
syntaxes are simultaneously supported by the default DB just to demonstrate
the possibilities.

outbound network connections:
the server object can connect any object to a legal IP address.  since parsing
is done in-DB, this object can easily manipulate the information it receives
from the connection.  for example, the default DB has an object called 'waldo'
that allows you to 'call lambda' to connect it up to the lambda guest.  Output
from lambda then appears on its 'monitor' and you can 'type' commands onto
waldo's keyboard to control the guest.

exception handling:
the error system is based on cardinal numbers, so users can define new error
conventions in the database.  error handlers can be specified for a specific
scope and a 'handler' method can be defined on the player to catch unhandled
errors along with an informative string about reason and location.

in-DB and in-room editing:
the editor was written in the same Coda code used by the rest of the DB, so
it is simple to customize and add features without learning a line of C/C++.
When editing a document, you stay in the same room as everyone else, talking
and posing all you want.


GEE-THAT-SUCKS REASONS NOT TO USE :
=============================================

Coda:
coda isn't your father's oldsmobile.  it's a bastard nephew of LISP, so
everyone who was told by their CS professors that LISP sucks will probably
not like it.  that's cool ... i don't care.  you don't have to rant to me
or the net about it since there are several dozen Pascal/C/shell-script
server langauges for you to use.
on the other hand, coda isn't LISP either.  LISP was designed for single-user
non-OO programming ... it allows you to change the value stored in symbols
in a lot of horrible ways that would totally destroy an OO, multi-user
platform.  LISP also has arcane old syntax that i didn't work too hard at
following.  this assumedly means that many real hard-core LISP programmers
will probably feel uncomfortable at first.

source:
the code is written in gnu C++, so you will need the gnu compiler and library
to even get it to compile.  if you decide you want to modify some of the
lexical analysis the server uses, you'll also need gnu's lexer. (flex)
i provide a copy of the FAQ for g++ in the documentation, but it's still
going to be more work to start from scratch if you don't already have the
gnu distribution on your machine.  (sorry ... gnu's as close to portable
i could come and still write in C++)

beta level:
the 'beta' in the version isn't just to tease you with future incompatibility;
it really DOES mean that there might be an error in my ~6000 lines of code.
maybe even two.  (three, tops.)  i'd REALLY love to work with others in
firming it up, so i needed to get it out there in the public eye in spite of
the fact that unknown problems must lurk in it's twisted source.  :-)

small database:
to justify my existance to the surrounding MU* community, i needed to provide
some sort of test-suite of operations that would allow people to connect to
the server and do a lot of the things that they expect a MU* to do.  so i had
to sit down and decide who i wanted to emulate (therefore, who to pander to)
for no real reason, the included DB emulates a Moo/tiny interface,
although it wouldn't really have made a difference to write a LP-esque
interface. (the multitasking, dynamic DB, and type system would make this seem
like a useful thing to do eventually)
i have no intention of fleshing this out into a big, huge emulator of that-
which-exists-now, however ... watch out for the new GUI-interfaced client/
server package i've got in the works ;-)  this is inteded as a demonstration
of one of the ways you COULD set things up, not neccessarily the best or
final decision.