Lists Home |
Date Index |
>Obviously size is not the only issue, loading performance appears to be
at least as
>important to most people using binary infoset formats and gzip alone just
>the receivers loading costs. There is a good paper linked from
>http://citeseer.nj.nec.com/cheney01compressing.html that discusses why
>compressing binary infoset representations can yield better compression
>results than gzip of XML.
In situations where load time is the critical issue, then using native
object marshalling with
lossless ToXML/FromXML utilities (item 3) on my list above, is the way to
go in my opinion.
Example. A very high volume wireless portal product that we built in
Propylon uses wall to wall XML.
Users, devices, transport protocols, locations, you name it - are all XML
For every HTTP request, about six XML files need to be parsed, turned into
native objects and then
some of them need to be written back out again.
When I first built the thing it took about 5 minutes to do a single HTTP
request/response. We got
this down to something more than adequate without resorting to knee-jerk
removal of the textual
nature of the XML underfoot.
The way we did it was analagous to the way Python compiles source files
In the system, each XML File Loader/Saver is responsible for maintaining a
native object serialisation for
each XML instance (in my case, Python/Jython pickles).
At load time, the marshalled object is read *if* the XML has not changed.
If the XML has changed, it is loaded and a new marshalled object is created.
At save time, the marshalled object is created first, then the plain text XML.
It works a treat and is fast enough to work within the tight confines of a HTTP
request/response pair thread on a heavily loaded portal.
No binary XML required, just a wee bit of thought about loading/saving XML and
prudent use of native object marshalling to get the best of both worlds.
Sometimes, I do the same by picking Pyxie trees. Also works a treat. Would work
just fine with DOM's etc.
With a binary XML you would still need to map to your native object model.
The whole perceived need for a binary XML notation goes away if we just
ensure that any object models - be they DOMs or application
specific - come with ToXML/FromXML utilities.
The benefits of that binary thing in the middle being
platform/product/application neutral are overstated in my opinion.