[Standards-JIG] PubSub efficiency was XMPP bandwidth compression
bob at wyman.us
Mon Jul 5 18:44:38 UTC 2004
Jean-Louis Seguineau wrote:
> "The key mistake in interop terms seems to be wanting to distort
> XML to fit the binary/api worldview or replace it wholesale at
> the system edges."
Yes. It seems that often those who champion alternatives to XML
often go to the radical extreme of trying to suggest that their alternative
should completely replace XML. But, that doesn't make sense.
The need for alternatives typically only appears in the exceptional
cases. Otherwise, XML is an excellent tool and has much to offer. XML is
widely understood, has great tool support, is easy to work with, etc. I
can't even begin to imagine an argument that would justify wholesale
replacement of XML.
What we need are alternatives to XML in those exceptional cases
where the "cost" of XML is too high. Currently, developers are forced to
work out the alternatives themselves (i.e. as Jean-Louis mentions, PubSub,
Antartica, Similarity Systems, and many others have done this). Some people
have made good choices, others haven't... But, in all cases, there has been
a great deal of duplicative work going on -- that duplicative work can be
reduced by working on standard alternatives (like Fast Infoset) that will
allow ready-to-use standards, implementations, tools, etc. for those that
really need them. (i.e. those with exceptional transaction loads, etc.) Of
course, even if Fast Infoset becomes widely used, it is inevitable that it
won't solve *everyone's* problems. This is inherent to the fact that we find
the issues with XML appearing only in the extreme cases. Nonetheless, I am
confident that Fast Infoset will solve quite a few people's problems.
In any case, I strongly feel that this issue should not be dealt
with casually or quickly. I'm very much afraid that people will, for
instance, just do the obvious thing and write standards that call for gzip
compression. It turns out that while this is an "obvious" solution to the
"size" problem, it is NOT the correct solution if you are also concerned
with speed of parsing, dealing with streaming data, implementing routers,
etc. If nothing else, we can note that none of the people who have
implemented alternatives to XML have found that gzip was sufficiently useful
to solve the problem...
Currently, few people have the problems that XML alternatives
address. We should avoid making quick decisions and implementing solutions
before the problem space is well understood. I believe that now is *not* the
time to consider XML alternatives in the XMPP space -- yet, we should be
doing what we can to understand the issues and preparing to deal with them
in the future.
Personally, I think the eventual solution to this problem will
involve very strong statements that XML is now and will remain the default
encoding for XMPP but that there would be stream initiation protocol
extensions to allow the negotiation of support for alternatives. What those
alternatives are should be a subject of a "battle in the marketplace" -- not
quick decisions made with insufficient data and experience.
More information about the Standards