[MUD-Dev] Re: Current Projects

Joel Kelso joel at ee.uwa.edu.au
Fri Oct 9 17:39:36 New Zealand Daylight Time 1998


Alex Stewart wrote:

> Well, after having just said that I don't have any topics to start, I'm going
> to go ahead and start one.. :)

> In particular:
>  * What kind of software are you working on? (MUD driver, MUD client, etc?)
>  * Why?
>  * What are its features?
>  * What does it do (will it do) differently than other things do?
>  * Any neat concepts involved?
>  * Any boring concepts being used in neat ways?
>  (you get the idea.. anything big I'm leaving out?)

> As for my answers to the above questions, I'm currently working on developing a
> fifth-generation MUD/MUVE driver written in Java (currently codenamed Lithium)
> designed to do all the things I've wished MOO and ColdMUD could do but can't,
> and to be a testbed for several new concepts I've come up with, including a new
> multiple-inheritance model, and a deadlock-free locking model for preemptive
> multitasking.
>
> Lithium will support a number of advanced features including preemptive
> multitasking, application-neutral design, a role-based internal security model,
> high on-disk database integrity and failure recovery, multiple internal
> programming language support, and a full object-oriented programming
> environment and DB-driver interface.

>   <URL: http://www.crl.com/~riche/lithium.html >

> Anyway, that's my pet project at the moment.  What's yours?

Visited the URL ... I'm writing Lithium, too :-)  Seriously, though, I'm just
hacking around, rather than starting out with any real design goals.  Lithium
looks like a great project.

I'm working on a server, written in C on POSIX with a feature set which will
look haunting similar, I suspect, to quite a few people.

    *    persistant, garbage collected object store
    *    first-class procedures
    *    dynamic inheritance O-O model
    *    lightweight multi-tasking (threading is internal to VM)
    *    extensible programming/database language support
    *    variable-boundary serialisation

By the last one, I mean the ability to detach fairly arbitary pieces of the
database, write it out, and import it into another running server which
shares enough common libraries.

Cheers,

Joel Kelso

-- joel at ee.uwa.edu.au --------------------------------------
"... great Scott, he's turned into _more than one person_ !"
"Well, there was always enough of him."
        - the Goon Show
-- http://ciips.ee.uwa.edu.au/~joel ------------------------







More information about the MUD-Dev mailing list