xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <james.david...@eng.sun.com>
Subject Re: [spinnaker] Announce
Date Sun, 09 Jul 2000 05:38:44 GMT
on 7/8/00 3:31 PM, Arved Sandstrom at Arved_37@chebucto.ns.ca wrote:

> I disagree. It's not quite "spot-on" to blindside people with stuff like
> this. Over on FOP we have no problems in letting people know about upcoming
> CVS branches and other developments.

Well, if you take a look at the source tree for spinnaker, there's probably
10 files checked in right now, if that. This *is* starting the discussion of
what a new parser should look like. It is my experience that if you
mumble-mumble what you want to do, it gets kinda lost in the noise. If you
actually start with some amount of commitment to it, then, well, things move
forward.

This is kinda what happend on tomcat-dev with catalina. Craig looked at the
code in detail, reviewed it greatly, said "I don't like this" and started up
Catalina. Several months later, the process of design and dicussion have
wound there way forward to a good piece of code that looks pretty
interesting. At the time he announced, there were those of us that felt a
bit hurt (especially since I wrote the first version of Tomcat while it was
still just an infant project at sun before it went Open Source), but after a
day or two of discussion, and introspection and seeing that things can
*always* be done better, I could see that his goals were in the right place,
so it wouldn't hurt going off and doing something.

> On a very related issue, as "developers" we don't spend most of our time on
> code. When we communicate, we communicate with design documents. UML,
> IEEE-compliant design descriptions, yada yada.

I don't see a lot of UML on Open Source projects. Typically we communicate
with code and mail. But that's a personal thing. I can hold a discussion in
UML as well as anything -- so what's your design for a NG parser? :)

> I personally don't want to
> receive a new source tree as the first deliverable.

Take a look at the spinnaker tree. There's not much there. In fact, some of
my friends were concerned that there should have been more. What it is is a
README that points out some obvious goals, then a few utility classes that
I've managed to pull out of Xerces so far (And I'm pulling out more as we
speak). You'll note that in the README I actually outline talking about an
API set, and moving forward from there. I would have actually felt bad about
checking in too much code at once because then it *would* have been a fiat.

In open source development, things get done because people push for them to
be done. It's important to note that the Apache process doesn't mandate
design by committee. It mandates openess and a minimum threshold
meritocracy. There's a difference.

I'm *starting* another source tree. The message was a call for
help/discussion/etc. I apologize if that wasn't more clear -- so let me make
it clear now:

Spinnaker is a something that I want to start here and now. I want *your*
help in making it something that can be good. It's wide open. No design
decisions have been made. You can affect it right now. SO, what would you
like to see in a parser today? :)
 
> I'm not trying to take the piss out of anyone here, as the British say. It's
> just that I've had a heightened level of sensitivity to all of this ever
> since I saw that Sun produced an XSL processor. Why did they have to bother,
> I ask? Were we actually lacking for decent XSLT implementations?

Quite honestly, I asked the same thing. Just so you know, it was produced by
a different part of Sun that I have no relation or connection to. It was an
engineer trying to take a new approach to the problem of XSLT.

And XSLT the spec is so new that we're not going to have a good answer for
what an XSLT processor looks like for a few years to come. I imagine that
the processor that we have in a few years won't look like Xalan 1.0 or XT or
the Sun one. What's the point if we think that we have the perfect peice of
software today? That's never the case.

There have in fact been many discussions about taking the XSLT compiler out
open source so that it can be further developed in the open arena and
compete on equal terms with the other parsers out there. If this happens,
may the best one succeed. Software isn't a cathedral where we're looking for
one perfect manifestation. Ideas come up, get compared, swapped around, and
later merge into something better. Not all software is destined for
greatness. But everybody should be given the chance to go off and do
something big.

> Mind you, jaxp is pretty good, but again, why jaxp when you've already got
> other better stuff? So when I see this I see a big corporate entity starting
> to operate by fiat. And it raises my hackles.

Do you mean JAXP the spec or JAXP the implementation (also known as
Crimson). There's lots of people that we know that like Crimson better than
Xerces. Lots of folks that looked at the Xerces code base, saw problems and
didn't really see a way to make a change. If I really wanted to start a war,
I would have pushed for more exposure and development of Crimson. It's a
decent enough parser that has different enough characteristics from Xerces
to be really interesting.

However, 1) I didn't want that war, 2) I wanted the next parser to be a
collaborative design... Done from the ground up in the open. Once again,
take a look at the source tree -- there literally *nothing* there. The
design is wide open.

> Speaking for myself, since I'm the release coordinator for FOP, if I saw
> that some group came in out of the blue and launched an entire new source
> tree I'd be pretty fired up. On any open-source project there is at least
> the principle of coordination. You can commit new source without
> consultation if it doesn't impact existing API's; new branches are a cut
> above that and require some feedback.

No, new branches are experimental. And at Apache, we encourage
experimentation. To the point where on the Jakarta project we created a
manifesto for it that expresses some of the points in use from early days of
Apache. I'll try to dig that out of the archives and post it somewhere.

Basically it expresses that anybody has a right to go off and create
something new. If people (developers and users) flock to it, then it's
something worthwhile and should be considered, if people don't, that sends
an equally strong message. At the end of the day, it only becomes the
santioned next version when everyone is convinced that it's the right thing
to do.

Changes to the main tree require more process, things on the periphery
should require no process. This is one of the problems with the Jakarta and
XML processes -- they have been influenced by corporate thinking and the
notion of processes has crept in -- and some amount of fiefdom. Some
companies feel that one project is theirs to own, and the other project
isn't something that they feel welcome in so they will shun it. I've seen it
in both my corp, and in other corps. And that's BS. These projects are owned
by Apache. And we play by Apache rules here.. And the number one Apache rule
is to collaborate and produce code (in fact the +1/0/-1 rule is about all
that we really do have in stone). There aren't many rules, and those that we
have change over time -- it doesn't work beautifully, but it does manage to
work.

Httpd 2.0 started out as a couple of people going off and hacking, then
other developers took a look at it. Only when everybody accepted it did it
become the descided next version of Apache Webserver. It could have died.
The same thing applies here, expect instead of grabbbing a few people and
starting to code, I sent out some email intending of finding some interested
people.

And if this code base doesn't gain any critical mass, I will be the first to
say it must die. That's a community process that doesn't need to be
expressed any more succinctly than that -- people use what they want to use,
people develop what they want to develop on. If a lot show up, then hey, the
barn raising moves forward. If nobody shows up, then there's a few
foundations that rot in the sun.

Apologies if the mail sounded like a done deal and there was a full working
parser checked in. Go take a look -- we're ready for the design discussions.

.duncan



Mime
View raw message