[
Lists Home |
Date Index |
Thread Index
]
Tim Bray wrote:
> Mike Champion wrote:
>> But the scenario I'm talking about
>> (see Noah Mendelson's bit, and Gudge's piece that Len quotes) involves
>> processes that are mostly building synthetic infosets, and
>> dealing with potentially thousands of messages per second. From what
>> I'm hearing from developers of high-performance
>> SOAP processors and XML middleware, that serialize/parse overhead
>> is significant, and they aren't doing it. They ARE reinventing
>> wheels, and want to do it just once (or some manageable number).
>>
>> My question is "given that they are not doing it with XML syntax, is
>> the world better off having a larger menu of standardized Infoset
>> serialization formats for high performance inter-process communication,
>> or better off letting these people roll their own without the benefit
>> of standardization" (Or letting them grow their own standards bodies).
I think Mike has summarised the problem very well here. People are doing, and
they are inventing wheels to do it. The problem is that their standard bodies
(when they go through them) are vertical. The binary infoset balkanisation has
already well started, and given that it does not restrict itself to closed
systems, I find this infrastructurally unsound and potentially toxic over the
not-so-long-term.
> I suspect such serialization formats are apt to be highly
> application-specific in their design. I'd need convincing that there's
> going to be one compact/binary serialization format that's a win across
> a wide spectrum of application needs.
I can only speak in full competence about BiM, but I can assure you that it is
not at all application-specific. I've obtained excellent results with a wide
variety of vocabularies ranging from SOAP messages to XHTML and over SVG,
NewsML, GML, SMIL, as well as many customer-specific schemata. For all of those
vocabularies, BiM beats gzip in compression and an XML parser in speed. Indeed,
it also has other features that are application specific, but given that it's an
evolvable, pluggable, and change-resilient format that guarantees
backward/forward compatibility that doesn't cause interoperability problems.
I fully understand your reluctance, but please do not start speculating on flaws
that aren't there :)
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
