Lists Home |
Date Index |
On Wed, Mar 27, 2002 at 12:29:33PM +0100, Nicolas LEHUEN wrote:
> Like I wrote before, I don't think that trying to stuff as many features as
> possible under the hood of the parser is a wise thing. I think we should
> have a lean and mean parser API (SAX2) and lean and mean parsers (less than
> 100 kb or JAR). Then, separated from the parser, you would have a lean and
> mean XML tree API (DOM2 for compatibility, or dom4j for functionality), a
> lean and mean XPath API (Jaxen), a lean and mean validation API (Sun MSV), a
> lean and mean pipe building API, and so on and so forth.
Nice rethoric, however:
- it seems to only be centered around Java
- SAX/SAX2 outside Java is a mess, especially for pure C
- running a minimalist prime number algorithm on a Java
machine seems anyway to use between 80 and 170MBytes of
virtual memory usage see the Test1 report from
So even if your jar is 100KB or even 1KB, I'm afraid you have trapped
yourself into the bloat by the way of your "there is a single development
infrastructure" premice, and much of the remaining arguments of your
post don't make much sense.
Unless I misunderstood, the Java performance report paper I point to,
or the guy is very biased against Java (which look unlikeley considering
it's an IBM developper work paper in the Java section).
I will stick to C thank you, even if this mean that designing the
code or API requires being a bit more careful.
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
email@example.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/