Return-Path: Mailing-List: contact general-help@xml.apache.org; run by ezmlm Delivered-To: mailing list general@xml.apache.org Received: (qmail 82598 invoked from network); 13 Jul 2000 11:37:07 -0000 Received: from systemy.systemy.it (194.20.140.20) by locus.apache.org with SMTP; 13 Jul 2000 11:37:07 -0000 Received: from apache.org (pv12-pri.systemy.it [194.21.255.12]) by systemy.systemy.it (8.8.8/8.8.8) with ESMTP id LAA17379 for ; Thu, 13 Jul 2000 11:37:04 GMT Message-ID: <396D04CB.F302CBBC@apache.org> Date: Thu, 13 Jul 2000 01:52:43 +0200 From: Stefano Mazzocchi Organization: Apache Software Foundation X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en,it MIME-Version: 1.0 To: general@xml.apache.org Subject: Re: [spinnaker] Announce References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 need". 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. Friedrich Nietzsche -------------------------------------------------------------------- Missed us in Orlando? Make it up with ApacheCON Europe in London! ------------------------- http://ApacheCon.Com ---------------------