[
Lists Home |
Date Index |
Thread Index
]
On Sat, Apr 19, 2003 at 07:25:19AM -0400, David Megginson wrote:
> The problem is that they often hit a point where they have no choice
> -- what works fine in the small, proof-of-concept implementation
> suddenly falls to pieces under real-world-scale load testing in a busy
> server. That's why we see so many programmers posting to xml-dev
> about SAX mid- to late-project, rather than at the during planning --
> they've come to the point where learning SAX is less painful than
> spending another month of late nights and weekends trying to figure
> out some other way to make their server handle more than a couple of
> hits per second.
>
> In summary, then, SAX is the root canal of XML programming -- you try
> less painful solutions first, but if nothing works, it's time to lie
> back in the chair, close your eyes, and open wide, to avoid losing
> your teeth altogether.
It all boils down to performances. In general SAX is the fastest
even if it makes the programmer life more complex. As a general API
it's hard to beat SAX for performances (unless the specific language
constraints makes callbacks expensive), it is still prossible to design
specific APIs which may be faster than SAX (for example when avoiding
callback costs for uneeded informations) but well they are specific...
> That aside, the other strength of SAX comes when you're going to be
> building an in-memory tree anyway, but it does not happen to be a DOM
> tree. Using the low-level events from SAX to build (say) a tree of
> geographical coordinates is much more efficient than building a DOM
> tree, then building a second tree of geographical coordinates from
> that, then garbage-collecting the DOM tree. In that case, most
> programmers in the project will never see SAX -- the load/save library
> should hide it completely.
Agreed, in that case the API the application programmer will see
is the load/save, and SAX is a good way to implement this layer.
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
|
