Fast Infosets, How are they coming along?

The last time I read and played little about Fast Infosets was a year and half ago when I am still developing "highly-intelligent crawling" stuffs for the telecommunications and broadcasting industry. As the name implies...

Fast Infoset specifies a binary encoding for the XML Information Set. An XML infoset (such as a DOM tree, StAX events or SAX events in programmatic representations) may be serialized to an XML 1.x document or, as specified by Fast Infoset, may be serialized to a fast infoset document. Fast infoset documents are generally smaller in size and faster to parse and serialize than equivalent XML documents.

Sun Microsystem has one project going on. This is really cool stuff since plain XML, which is really one of the necessary evils when it comes to performance bottlenecks. Most developers, just to say they have used XML in their resumes, will really do stupid things at the expense of performance, to any type of 'XMLing' in their apps. In effect, we have a lot of heavily XML dependent frameworks. On the other hand, a lot of things won't be possible without XML. Adaptation will be one of the challenges Fast Infoset will have to tackle. Imagine if we want Spring to be more bouncy then there's a lot of work to be done in making context bean factories work with Fast Infosets. Web Services especially, the WSDL has to be modified if we to have a faster SOAP XML interoperability. Apache will also have a lot of refactoring to do make Fast Infosets really work for them.

But if we want to break the barrier of XML-burdened performance, then Fast Infosets needs to be adapted as soon as possible.


maks said…
hmmm interesting topic. I wonder if infosets would become efficient if you want it done fast.
Jared said…
They are efficient. It's just the DOM is more error-prone if any gung-ho vi-emacs-notepad-lover geeks will attempt to dissect it.

Popular Posts