SAX: Distributed Implementations

[David Brownell]

>  > I'd probably not split a real application in that particular way,
>  > though.  The latency penalty for lots of fine grained syntax
>  > callbacks hurts, and distributed systems are generally designed to
>  > ship bulk data (such as an XML message) and process it locally
>  > (such as parse, interpret, respond to some purchase order in XML
>  > while updating several databases).  HTTP is only one of the more
>  > visible examples of that trend.
> 
> This wouldn't be too much of a problem with a remote character or byte
> stream, especially since we've removed the single-character and
> single-byte read().  AElfred, for example, slurps up 32K at a time
> into its read buffer.

Sure -- but with each slurp of 32Kb, it can be doing thousands of
syntax callbacks.  That easily adds up to seconds of overhead, even
assuming an idle network (no contention).  A few years ago I used
200 calls per second as a standard OO RPC speed estimate; it can be
faster, but it can be slower too.  And "faster" is not an order of
magnitude faster.

Those callbacks were the worrisome part of your scenario ... :-)


> By the way, Java is simply the initial implementation for SAX, but it
> is not intended to be the only one.

I understand this.  But since the master spec isn't in something like
IDL, then you're already committing to language-specific translations
and customizations ... how do you decide which things should be custom,
which shouldn't be?  You're not making the tradeoffs I'm used to seeing
when people design systems to use in multiple languages.

- Dave


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)