Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
http://www-106.ibm.com/developerworks/java/library/j-native.html
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
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard@r... | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
|
