xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [spinnaker] Announce
Date Wed, 12 Jul 2000 23:52:43 GMT
Scott Boag/CAM/Lotus wrote:
> > would you trade (a little) performance for a healthy and open community
> > of developers?
> Um, perhaps.  But the whole concept of XML already has performance issues.

Sure, like anything else.

> Especially with a parser, people (users, products) don't really care about
> the code... they need it to be fast enough to please.

Really? I first want a stable, usable and compliant software, if then
it's fast, great, if not, throw some hardware at it.

> Even the fastest
> possible parsers may have problems pleasing, esp. since it really looks
> like XML is totally taking over the world, and will have to please a very
> large constituency.  (I'm down in Florada at the MS developers conference
> right now, where they are unveiling there .NET architecture, which is
> totally XML based).

Blah, you mean filling the gaps the hype is creating? now way you can do
that. Most people I talk to (outside Apache XML) believe XML is just a
more complete HTML. A language, not a syntax.

I've seen SAP marketing about "XML support" which is just using the XML
syntax to do _exactly_ what you were doing in the past.

I almost puked on the screen.

B2B was bad enough, now microsoft creates the ultimate hypeware and
calls it .NET, go figure.

Remember "640Kb will be anything you'll need"? Later we had "Internet?
MSN will blast it". Then "why should we be scared by Java?". Moreover
"The network computer is shit". And now "XML is everything you'll even

Knowing the mistakes they keep doing over and over, this scares the crap
out of me.
> I'm well aware of the different constraints of open source vs. commercial
> development.  If the parser folks do their job right, hopefully we can have
> both optimal performance and understandable code, but I would still put
> performance a notch higher, or at least bound to the fact that it must be
> commercially viable from a performance perspective (the same is true for
> the Apache HTTP server, I assume).  If it ain't fast enough, nothing else
> matters.  Just my opinion, based on my perspective.

Which I totally dislike. The Apache HTTP Server is _not_ the fastest web
server available, but it's the most solid, compliant, modular, useable,
flexible, open, tested, appreciated.

Try asking around if people would trade speed for any of the above.
You'll be surprised for the answer.

> The best optimizations often come from algorithmic tuning, rather than code
> tricks, and these kind of optimizations, especially at the stage that
> Xerces and Xalan are at, are helped, rather than hindered by clean,
> understandable code.  Knowing you, I'm pretty certain that we are in
> violent agreement on this.

Yes, totally.

> On the other hand, there may be system level
> complexity introduced by these algorithmic tunings, like the use of string
> pools in Xerces.  Do you suggest that Xerces shouldn't use string pooling?

If the code becomes utterly unreadable and the community stops working
on the project, yes, I do.

> From what I've heard and experienced, string pooling makes a major
> difference in the performance.  I would keep the string pooling for
> Xerces2, in spite of the increase in complexity, unless someone can prove
> it doesn't make a major difference.

Hmmm, I wonder if AspectJ could help on this....
> Mind you, performance is a relative thing.  Since the parser is a very
> generalized entity, compromises in performance will have to be made for the
> sake of layering.  This can't be helped.

Oh, totally.
> BTW, C# looks pretty damn good.  :-)

You can't be serious on this...

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message