A Simple Thought

[roddey at us.ibm.com]

>Ahh, there's the trick.  I believe I have most of a design for an data
structure
>that is fast in memory yet is 'flat' and can have its chunks just written
out or
>read in at any point.  It builds on some very old ideas I came up with for
a
>language I designed.  When viewed as an interchange format, it may not be
the
>most optimal space wise (although it should be better than XML text) but
trades
>a small amount of space for nearly zero processing overhead.  There will
>probably also be a procedure for 'compacting' an object for storage into a
>database or sending over a slow link vs. the 'fast' format usable between
>servers in a cluster.
>

I think though that this would only hold up as long as you are looking at
XML data as a read-only data source. Once you started doing significant
editing of the data, having a flat structure like that would be more of a
hinderance than a help, would it not? What if I have a 10MB flat buffer and
want to add another child to the second element? This kind of gets into the
quandry that you've nailed in one nail, but now its even harder to nail a
whole raft of others as well as with the more general purpose mechanisms.

I dunno, if I were thinking along these lines, to keep it reasonably
portable, I'd look at the binary format as a fast serialization mechanism
and at least create native language objects for each one. By the time you
put enough stream format markers and whatnot into the stream to know where
things are, and interpret those during runtime, it might be just as fast to
pay the cost for creating a much more flexible, native object format for in
memory manipulation.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)