[DGD]serialisation/deserialisation of mixed data.

[balduin at uni-paderborn.de]

> balduin at uni-paderborn.de wrote:
> > <munch> <munch>
i hope i'm tasty ... ;)

> [...]
> > I need to store references to persistent Objects (from a database)
> > in a way that serialisation as well as deserialisation is possible. 
> > Assume each persistant object can be retreived from a persistant and 
> > uniqe ID from a database.
> 
> I take it that you want to serialize as a byte stream for
> communication between two muds?  If it's anything else, you are
> trying to solve a problem already solved in DGD itself.

Right, this part of the stuff looks pretty much like dgd with a 
state dump. The reason to store the objects in a database and not
in the dump file, is that I need the advanced searching abilities
of the database. I plan for an educational environment where the 
users (pupils/students) can handle their course material, do homeworks,
and so on, while talking about it. All texts and documents they use
will be represented with mud objects (stored in the database). But this
approach will on the other hand allow for searchable keyword lists and so
on.

> 
> What are these objects doing in a mysql database?  If they really
> have to be, I'd implement this as a kfun rather than in LPC, so
> you can use DGD's mechanisms for delayed loading of both objects
> and arrays/mappings.

hmm sounds pretty nice ... really.

> 
> 
> > The problems are:
> >
> > I can't use 'object' for two reasons:
> > a) In case of recursive Datastructures deserialisation would implicitly
> >    mean recursive loading of possibly the whole mud. (A container in a
> >    container in a cointainer etc.)
> 
> Perhaps you mean "nested" rather than "recursive"?

yes ... where is the difference ? Or would recursive mean the container
containing itselves.

> 
> 
> > b) I plan to use dgd's objects as kind of cache for the persistant
> >    objects. This means to free up main memory, I have to remove old objects 
> >    from memory, but can't afford to loose the references (They have to be 
> >    persistant as well)
> 
> This suggests that you're not transferring data between muds, but
> keeping everything within a single mud.
no ... yes ... indeed.
> 
> Are you sure you want to store LPC datatypes wihin a mysql database,
> redoing what's already solved in DGD? :)

yes ... since i need the search abilities of the database and expect
a lot of documents/objects if I ever come to the point to test the 
system. One part of the system will be (is) a html server and to achieve
link consistency every single bitmap has to be an object.

> 
> If you are really, really sure, I suggest handling this at the kfun
> level rather than the LPC level, so you can make use of DGD's well-
> developed persistence and delayed loading code.  Further suggestions
> will have to wait until I know more about what exactly you have in
> mind.
> 

Tell me what you need to know, your suggestions are always welcome.
If I'd feel a bit more comfortable with writing english i'd already
given a short project description to you.

contact me with balduin at uni-paderborn.de if you feel this 
problem is not suited for the mailing list.

regards (i looked up this term ;0 )
Ludger

(balduin at uni-paderborn.de)

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