Re: Request: Test suite for EFS.

[Nat Friedman <nat helixcode com>]

Daniel Veillard writes:
 > 
 >   I afraid you are gonna object that you don't have time to pusue the issue
 > that it's too complicated and you have a product to ship. I already got this
 > argument for not switching gtkHtml to the libxml/DOM code. I feel concerned
 > about this. Until now Gnome was very nice in the sense that people took the
 > time to stick to Do The Right Thing even if it was a bit more
 > painful/slower.

    Dude, this is silly.  I sent mail saying "let's figure out how to
do XML" and you respond with "You are not considering XML because
you're eeeeeeevil!"  A few deep breaths on either side seem like a
good idea to me :-).

    For the record: I do want to use XML.  Now, let's work out how we
can do that.

 >   The Right Way to do this in XML is to use namespaces.
 > I *strongly* suggest you read :
 > 
 >   http://www.w3.org/TR/REC-xml-names/
 >     
 > It starts with:
 >     "We envision applications of Extensible Markup Language (XML) where a
 >     single XML document may contain elements and attributes (here referred
 >     to as a "markup vocabulary") that are defined for and used by multiple
 >     software modules. One motivation for this is modularity"

    Yeah, namespaces do seem like a really good idea in the case where 
the embedded component can persist itself to XML.  I do wonder whether 
or not we want to require this, though.

 > When designing the original gnumeric XML serialization I did put a
 > namespace

    Yeah, the gmr namespace.  Cool.

 > Read the short stuff I put on
 > 
 >   http://xmlsoft.org/#Namespaces
 > 
 > too.

    Neat.  I do wonder in which situation we would want to validity-
check an entire compound document, though :-).

 >   I did send mail to Miguel about how namaspaces should be used in bonobo
 > to switch/detect compound in document serialized in XML. This was requiring
 > registering the XML namespace URL for each application and make sure
 > that all serialization would declare the namespace, and build XML analizers
 > in a way flexible enought to skip element not in your "own"
 > namespace.

    Can you please resend this mail to the list?

 > >     What OLE2 does (as I've described before on this list) is just
 > > write the activation ID in straight (this is especially easy since
 > > their activation IDs are fixed-length) and then dump in whatever
 > > stream the component spits out untouched.
 > 
 >   How are activation ID allocated ? Is that a registry ? who
 > maintains it ?

    The activation IDs are just GUIDs that a component registers into
the naming service.  They're the equivalent of GOAD IDs.

 > >     So using XML makes me think "scary buffering."  But maybe I'm just 
 > > being timid.
 > 
 >   I don't understand. Are you just considering the memory requirements ?
 > I'm considering designing a serialization model which will be stable over time
 > and still readable in 20 years by generic tools.

    I'm just constrasting the simplicity of the OLE2 compound doc
storage model to the internal complexity of using XML -- with OLE2,
they don't even have to buffer any of the streams.  Compound document
persistence looks like this in the OLE2 world:

    foreach embedding in embedding_list

        activation_id = embedding.get_activation_id ();
        write_to_persist_stream (output_stream, activation_id);

        embedding.persist_to_stream (embedding, output_stream);

    next embedding

Depersistence looks like this:

    while not eof

        activation_id = read_from_persist_stream (input_stream,
                                                  activation_id_length);

        embedding = activate_component_with_id (activation_id);

        embedding.depersist_from_stream (embedding, input_stream);

    end

This is just incredibly simple to implement.  And with XML it's
harder.  This is a tradeoff; XML has many advantages over the OLE2
approach.  I was just pointing out one issue.

Nat