[DGD]Persistence and Object Databases

[Par Winzell]

 > Running a persistent/continuous mud makes issues that were once
 > important incredibly vital.  One such issue is object leakage.  By
 > that I mean objects that are out there floating around -- the kind
 > of objects that would be clean_up()'d as it were under MudOS.  In a
 > persistent mud, one can imagine all sorts of causes for this.

Indeed.

 > Now a well written object daemon will keep track of all objects and
 > their various relationships (inherited by, inheriting, clone of,
 > etc.).  At least in theory.  But the object register daemon,
 > partly, duplicates information already contained in the dump and
 > swap files.  That is to say the dump and swap files are the
 > ultimate authority on what objects exist and their relationships to
 > each other.

Yep.

 > Now given the critical nature of this information--what objects
 > exist, at least--it might be nice to have some redundancy.  Is
 > there any way to get information directly from the ultimate
 > authority (the dump and swap files) such that any discrepencies
 > that might crop up between it and the lib side object register can
 > be resolved from inside the lib?

Yes. Download the DGD source, examine the state dump building code,
and write a program that rips it apart and analyzes it. Or, perhaps,
attempt to graft the relevant dump-reading parts of DGD onto control
code of your own making (probably difficult).

Richard Braakman wrote such a dumpfile analyser (in LPC!) which would
probably make a good start for such a project. I believe it's a bit
dated now -- I don't think it supports compressed strings, and it may
be the format has changed since -- but it's definitely doable.

 > Something like a kfun that returned a list of all existing objects?  Is 
 > there a way to use status() to do this? (I don't see it offhand).  I 
 > considered cycling through all existing files, but one can also envision 
 > discrepencies arising between the dump/swap files and the mudlib source 
 > code. (Someone moves/deletes a file shell side.)

I do personally think it would be nice for some very low-level kfun to
return such information, but I'm not sure Dworkin has any interest in
such a solution. If one of Skotos' games ever need this kind of hands-
on healing, what I will probably do is write a dump-file shredder and
some LPC code that outputs the kernel library's and the mudlib's idea
of what objects exist where; both pieces of code will output on exactly
the same format, and a diff -c between the two will tell you what's
wrong.


 > How have other people addressed this issue?  Perhaps it's a non-issue?

I think it's a very interesting issue!

Zell

List config page:  http://list.imaginary.com/mailman/listinfo/dgd