xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rod McChesney <r...@expressaction.com>
Subject Re: [spinnaker] Announce
Date Tue, 11 Jul 2000 23:32:31 GMT
> >> I am willing to trade off some performance for clearly written code.
> >
> > I don't think I am.  Performance is too damned important in the XML
> > world...

Here's a field report on choosing parsers. At a previous company
we had relatively large XML documents that were parsed on the 
server side. We used Xerces to good effect; size was unimportant on the 
server and speed mattered.

Where I am now we use XML as a wire format, so the data volume is small, 
and parsing takes place on the client (the customer's e-commerce
environment) and on the server. Small footprint (memory *and* disk)
are much more important in this context than speed or even validation. 

Current Xerces does not fill both these needs; I don't think there's
any argument there. So I welcome an effort to cover both kinds of 
environments. The brief excursions into the Xerces code that I made
left me a bit baffled, whereas I could follow what JAXP was doing much
more easily. In my environment we prefer to not change code in libraries,
but we do look at the source to understand why something's not acting as 
we expect. The upshot of this is that a cut-down Xerces seems unlikely
to fulfill the requirements of different environments. 

These comments are *not* intended as further flamebait, just as input
from someone using the end product as a customer rather than as a tool
developer.

Rod McChesney


James Duncan Davidson wrote:
> 
> on 7/11/00 3:25 PM, Scott Boag/CAM/Lotus at Scott_Boag@lotus.com wrote:
> 
> >
> >> I am willing to trade off some performance for clearly written code.
> >
> > I don't think I am.  Performance is too damned important in the XML
> > world...
> 
> You're not going to get a diverse developer community built around code that
> is too damned hard to read...
> 
> There are servers that perform faster than Apache, because after all,
> perforance is imporant on the web. But, they aren't as flexible,
> maintainable, and open -- nor are they backed by an open development
> community that gives anybody the ability to get involved.
> 
> That's not to say that performance isn't a important requirement. It is. But
> I'll trade *some* amount of that top end of performance (which, due to
> benchmarks is typically only in specific cases *anyways*) for code clarity.
> 
> .duncan
> 
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org

Mime
View raw message