[MUD-Dev] DBs and Events

[coder at ibm.net]

On 10/02/98 at 10:52 AM, Greg Munt <greg at uni-corn.demon.co.uk> said:

>Am looking for some (web) references to disk-based databases. Can anyone 
>help? Advantages and disadvantages of using (only) GDBM to provide a mud
>DB?

dbm and most of its extrapolations (including ndbm, gdbm, tdbm and
company) have some fairly severe performance and storage considerations. 
There is some (not much) discussion of this at the FreeDB page and in
their relevant documentation.  The docs for YOODA and LINCKS I recall also
working over that area lightly.  The little work I've done with ndbm has
shown it to be extremely sensitive to its choice of hashing algorithm for
the large-ish databases I was using (2 - 3 million records, frequent
accesses, very infrequent updates, very small records).

The MUD end is of course rarely mentioned.  Stephen White goes into it
lightly with his original docs for CoolMUD (still the most elegant and
downright sweet server deisgn I've seen yet), but mostly with the comment
that Marcus Ranum's DB code is par excellant.  Marcus Ranum was the
original champion of disk DB's as more performant than in-memory (due to
page fault penalties), and thus wrote UberMUD as a successful proofcase. 
You may be able to dig up some docs from him on the area (please repost
here -- I'm extremely interested).

Nathan validly questions the use of a DB at all for a MUD.  While I don't
agree with the extent of his argument, I have come to the view that a
classical DB is a questionable choice, and have thus been moving much
loser to a persistant store type model.  I'm not aware of much stody in
this area.

>Also, any references to caches?

Most OS and compiler design books (I don't have the dragon book to hand to
check it in particular) have texts on one, two, and three level caches. 
There are also a goodly number of web references.  One thing I would
remember is that the benefits of cache are incredibly dependant on load
characteristics.  Very small changes in the type and pattern of accesses
can vastly increase performance with one cache design while getting little
or even a negative effect with another (cache overhead).

>Any references to Event Management? 

Yup.  Get "Design Patterns" by the gang of four.  Read it.  Study it. 
Sleep with it.  Marry it.  Mind meld with it.  Incredible book.  Worth
thrice its weight in Uranium 238.

>Is there any alternative to using a 
>pointer to a function, to store the Event->function()? 

Yup, several.  I use message passing with the result that the
function/method bindings are very soft.  Again, see "Design Patterns".

>(This has the 
>disadvantage of every Event->function() needing to have the same number 
>and type of parameters being passed to it.)

No, it doesn't.  There are many routes around this, encluding casting down
and back up to devalue the argument characteristics, wrapping all
arguments in a structure or class to result in a single argument and than
passing that, not using a function binding at all and using very light
weight message passing, and a very large host of other possibilities.

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...