[
Lists Home |
Date Index |
Thread Index
]
[Quoting from Bray, St. Laurent, and de Hora ...]
> >>Pelegri-Llopart said "The main point here is there
> is almost an order
> >>of magnitude between straightforward Web services
> using XML encoding
> >>and an implementation that takes care of binary
> encoding."
Is anyone disagreeing with that assertion? I hear it
from a lot of apparently independent sources.
Presumably we'll see data at the "Binary Infoset
Serialization" workshop next week.
> > It makes sense to me, given the low-to-negative
> value that most
> > developers of projects in that space give to XML
> as anything beyond
> > "something which has lots of toolkits".
Uhh, yeah. There are a lot of tools that work off some
variation of the XML Infoset (DOM, XSLT, XQuery, SOAP
...).
>
> Fwiw, time invested in XML parsing would pay
> dividends.
> Crimson/Xerces ain't nothing to write home about and
> they seem to
> have the lions share of deployments in Java-land.
Not in Web Service land, AFAIK. The WS tool vendors,
or at least those who go for the high-volume,
industrial strength market, write their own
SOAP-optimized parsers.
>
> Find a customer and imagine which you think they
> want to hear- "yes
> its slower but it'll be up in 12 weeks, cheap and
> cheerful, and
> anybody in oppers can read what's coming in off the
> wire", or "yes
> it blazes but it'll take six months cost more, and
> no, oppers won't
> be able to understand anything".
"Oppers" == "operations staff trying to debug the
bloody thing" ??? :-)
This (and Simon's point about tools) raises a very
interesting question: is the more-or-less-indisputable
fact that one can get an XML distributed app up and
running much faster than a proprietary-format
distributed app due to the standards-ness of XML or
the text-ness of XML? If you took away the text-ness
but put an alternate standard (or two, or some very
small number of standards) in its place, how much of
this implementation efficiency would you lose? How
much time do "oppers" really spend debugging XML
streams, and would their productivity suffer if they
had to use some little tool rather than Notepad do so?
[Not a rhetorical question ... I really don't have an
opinion on this].
>
> If there are plenty of customers who are deeply
> concerned about
> performance then maybe this work has value, but I
> still think
> optimizing the parsers is a better strategy,
There are an awful lot of people out there working on
closed source optimized SOAP-XML parsers, again AFAIK.
I have enough faith that Sun hires sensible people to
be fairly sure they tried this before -- probably
reluctantly -- concluding that ASN.1 has a lot of
advantages IN THE SPECIAL CASE where all parties know
the schema of the data on the wire. In the case of
SOAP, the middleware doesn't have to know the schema
of the SOAP body, just that of the headers that it
understands (e.g. WS-Security, for firewalls).
> even if you proved
> it wasn't, I think I'd look for a briefer text
> format first
> (xml2rnc for example), before I'd get into binary
> codecs.
Yup. It would definitely be interesting to see if
something akin to RNC might be both more
human-readable and more machine-efficient as an
Infoset serialization format, at least for certain
niches.
As best I know, the big win for truly binary XML
serializations is in avoiding the overhead of the
Unicode-encoded text to UCS-character translation.
Does anyone take issue with the assertion that the
external encoding-> Unicode text translation is
generally a significant portion of XML parsing time?
Of course, the big downside for all alternative
serializations is that they seriously limit
interoperability. But remember that the whole POINT
of this "efficient alternate serialization of the
Infoset" stuff is to buy performance at the cost of
some interoperability, to be used in specifically in
situations where the pain of worse performance is
worse than the pain of lower interoperability. And the
whole point of standardizing a small number of
alternative serializations would be to get some of
that interoperability back.
|
