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 Tue, 11 Jul 2000 13:25:39 GMT
twleung@sauria.com wrote:
> 
> Let me make a few comments on this whole episode.
> 
> 1) If any Xerces developer at Sun or IBM wants to hassle someone
> for wanting a revolution in the Xerces codebase, then they should start
> with me, not Duncan.  I was the one who suggested that all the people
> working on Xerces take a deep breath, eat some humble pie, and admit
> that there are problems with both Xerces and Crimson.  So lay off of
> Duncan.   The current Xerces code base is based on a design rule which
> says, "write a Java program in an idiomatic style that mimics what you would
> do in C".  As a corollary, "If anything gets in the way of going fast, crush it".
> I remember specific instances where things that were interfaces got turned into
> classes solely because of the performance impact of method invocation through
> an interface as opposed to a class.
> 
> 2) As a former member of the IBM team in Cupertino, I have to agree that general
> visibility into the development state of Xerces is non-existant.  Sure, I can pick
> up the phone and call Mike, Andy, Jeff or Arnaud and get the exact details on
> what's going on.  But I shouldn't have to.  It's 9 months after the initial contribution
> of IBM code into Xerces, and the majority of the development is not happening out
> in the open.
> 
> 3) For whatever we do in the future, I would like to see the requirements clearly
> laid out, so that we can view both the Xerces and Crimson codebases against those
> requirements.  The creation of that requirements document must be a public community
> activity.  Similarly for a design document.
> 
> 4) For the record, the code base that is now called Xerces underwent at least 2 major
> refactorings and rewrites before it was donated to Apache.  There is a reason that it
> is the way that it is.  The primary criteria were "compliant" (whatever that means) and
> "fast" (which meant faster than whoever else happened to have an XML parser).  We
> understood some other requirements.  Some of them got trampled by the above 2.
> But there were lots of other interesting requirements.  I think that now is a good time
for
> some of those to be considered.  At one point , we conceived of a family of parsers,
> tuned for different scenarios, but making have use of a common pool of code.
> 
> 5) I'll go on the record as being in favor of controlled revolution.  For me one of the
> attractions of open source development is the possiblity that we engineers might actually
> get to build something that we're proud of, having been released from the corporate mandates
> of schedule and feature creep.  If you look at what's happening in the Linux kernel,
they are
> periodically having a revolution -- just watch the linux-kernel list and see how many
people
> are screaming about 2 different VM implementations, or "last minute" upheavals in the
device
> driver architecture.   All production code that I've ever worked on has eventually turned
into
> a steaming pile of **** because it was impossible to throw it away.  I'd like to see
a place
> where interested members of the community can fool around with ideas without being subjected
> to the pressure of "This Xerces 2.0", or "this is the main trunk so don't break the build",
or any
> other pressures.
> 
> 6)  I'm actually more interested in services API's around the parser than the parser
itself.  That
> includes stuff like JDOM, or databinding, or other parser APIs.  I'm profoundly unhappy
with
> the W3C DOM (sorry, Arnaud), and if it was up to me, we'd just heave the entire mess
in the
> garbage and leave it there.   It takes more work than it should to build an XML producing
or
> consuming application.
> 
> 7)  I suppose now I'll be chastised for posting this at 3:45AM when all sane people are
sleeping, except
> for the ones reinstalling their operating systems.  Um.  Really, folks, this is getting
to be an ugly place
> to be around.  If we can't make this a civil community and learn to work with each other,
there isn't
> going to be a next-gen parser, and the IBM folks in Cupertino are going to be the only
ones who
> work on Xerces.

Amen.

Ted is the man.

> P.S.  Duncan, the next time you want to have people come violently into agreement, could
you just
> send an H-bomb, instead of e-mail?   Might be less mess.

Like I said, shit happens.

But I'm sure James learned the lesson very well ;-)

-- 
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 ---------------------



Mime
View raw message