Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Pushing all the buttons
 [Kevin Jones] >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 increases >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 instances. 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 into bytecode. 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. Sean http://seanmcgrath.blogspot.com 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
