[MUD-Dev] TECH DGN: Re: a few mud server design questions (long)

[Kevin Littlejohn]

Robert Zubek wrote

>> On the other hand, you must consider how much work you want to
>> put in to writing the ideal system compared to how much you want
>> to explore AI in that context.  You can readily simplify and cut
>> out a lot of hassle, at the expense of scalability,
>> extensibility, etc.
 
> well, i'm happy to take the time to explore design issues - even
> though i might not be able to implement some of them (such as full
> transactional rollback, or good object persistence), it's still
> good to know what the best solutions are. besides, lisp has a way
> of rewarding clean designs with quick prototyping turnaround. :)

I've been busy not responding to this thread, but I really should, I
guess: Moebius has most of the two above (object persistance and
transactional rollback) implemented now.  Object persistance has
been stable for a long long time - I'm using MySQL as a data store,
but slowly abstracting to allow other datastores to be plugged in.
Transactional stuff is new, and not quite complete - it rolls back
if an error is raised, but not if there's a collision in reads and
writes (that's a two-line patch I haven't put in yet for no good
reason), and only applies to certain types of attributes - but it's
using the scheme described by Miroslav Silovic at
http://www.kanga.nu/archives/MUD-Dev-L/1997Q3/msg00246.php

I'd love to chat to people about this stuff - I have a running
instance of moebius at moebius.bofh.net.au port 5000, the web pages
are at http://moebius.bofh.net.au/ and there's a mailing list linked
from there.  I'd dearly love to find people interested in helping me
with coding - only so many hours in the day, and all that ;) If
you're going ahead with building the LISP based thing, you might
want to drop in and chat - chances are there's at least me, and
someone else who's written something very similar in perl, who might
be able to help you with some of the more interesting bits (or suck
ideas from you for our own work *grin*)

Oh, on the scheduling: We have an unbounded time-sorted event queue
- just pop the next event off and let events reschedule themselves.
Transactions encompass a single event only.  The event queue is also
persistent - it survives reboots, and catches up, so it looks like
you're always up ;)

Message propogation would be a lib-level thing, not an engine-level
thing, so I haven't really put too much thought into it, beyond
discussions I had off-list with JCL many moons ago, that involved
many strange event-shielding bags and collapsing bridges, most of
which are in the kanga.nu archives (ie. JCL's talked about them
before) somewhere if you really want to worry about the corner
cases...

Security and distribution are the other areas you haven't discussed
yet... ;)

KevinL

--
Internet techie                    Obsidian Consulting Group
Specialising in proxy servers and traffic measuring/billing.
http://www.obsidian.com.au/           darius at obsidian.com.au


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev