[DGD]serialisation/deserialisation of mixed data.

[balduin at uni-paderborn.de]

Hello !
>
> [...] 
> I guess I'm having a hard time understanding why documents, bitmaps, and
> other served entities need be an actual objects.  To me, that would
> significantly slow down the serving process as the object would need to be
> converted to the protocol's expected stream.  Am I missing something?  I
> agree, though, if you were expecting to max out your object count, an SQL
> solution might be called for.  Could you explain your motivation for using
> objects to encapsulate everything?

The plan is to create something like a library in this mud. (Special
rooms for discussion, lessons and so on will follow) The books are
to be represented as objects in the rooms of the library (storage systems
like shelves will be implemented if it seems to make sense to structure
the documents any further). As a representation in the mud for the documents
thus an object (call it book) will be needed. The document contents will 
be kept in either the filesystem or the database or even a special
mutimedia database (not sure yet) a function lets say get_html() in each 
object will either return a filename or an html stream for the httpd to be 
send to the requester.

A java client is meant to contact this server, the equivalent of 
'look at book' or 'read book' will initiate a http request (perhaps
from a netscape or internet explorer) to display the document contents
there. A different approach is to use the java-bean WWW-browser to
get more platform independence.

The most obvious approach to handle documents uploaded to this mud-server
seemed to be to create a representation for any file (e.g. pictures) in the
library. I will reconsider this approach, since it might be confusing, if
I can see the book and it's pictures both in the library. But I fear the
work to parse html if i have to adjust url's includet in the documents.
But dgd's parse_string function may become very handy here.

Another benefit from "objects as representation for documents" is the 
possibility to store additional attributes, e.g. private annotations of
pupils there. Enhanced access methods also can be implemented here.


So far this time, it looks as if I really have to post a bigger
"project description" to the dgd mailing list, though i doubt thats
the proper place for this.

greetings 

Ludger

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