[MUD-Dev] DBs and Events

[Nathan Yospe]

On Tue, 10 Feb 1998, Greg Munt wrote:

: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?

Can't help you on this. All active stuff exists as patially instantiated
in-memory references for me... not exactly an object model, and no DBDB.

:Also, any references to caches?

Again, can't help you. I've done caches, but not for my mud... and there
is such a broad spectrum of things that qualify as cache. Do you want to
know more about cached in-memory storage for a disk-based DB? Using your
registers as cache for iterated short strings of instructions? Caching a
file or two off the net the way browsers do? Or bottleneck spot caching?

:Any references to Event Management? Is there any alternative to using a 
:pointer to a function, to store the Event->function()? (This has the 
:disadvantage of every Event->function() needing to have the same number 
:and type of parameters being passed to it.)

Here we go. This I can help you with. Events don't have to be functions,
for a start. An event could be stored as anything, from a script on down
to a held thread. I store mine as classes... any action is executed from
an event class, which grabs the nearest available execution thread, sets
it to the event's references, and frees it to go. Events are, by design,
only actually capable of grabbing one specific thread, such that any set
of events cannot execute asynchronously on the same resources. Functions
are actually pulled up _after_ execution begins... Event.Process() is at
its basis a normalization check, which tries to match a list of objects,
and upon success, changes the values of the objects to a new norm, then,
with its still-active thread, allows those objects to update. The object
update methods are the actual functions involved, and once each object's
updates are complete (and affected objects with zero delay complete such
updates as the modified objects have made available) the thread is wiped
clear of variables, set to sleep, and returned to the pool. This is just
one approach to events that doesn't actually require a function pointer,
and a good number of others can be found in deja news archives of thread
and event related newsgroups.
--

Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Physics student, University of Hawaii dept of Physics
yospe at hawaii.edu nyospe at premeir.mhpcc.af.mil http://www2.hawaii.edu/~yospe/