You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Eduardo Pelegri-Llopart <pe...@eng.sun.com> on 2000/01/04 00:57:42 UTC
re: open processes...
First a clarification: I have been following jakarta, tomcat, xerces,
xalan, cocoon, (JSP-interest & Servlet-interest), et al. via digests,
since I get quite a bit of other mail every day. Unfortunately,
digests make it difficult to properly participate in email
conversations; and, to make things worse, digests from all the apache
sites were not sent for a couple of weeks.
Assuming software works properly, I will switch to undigest on Tomcat
starting tomorrow. I hope that will make me more responsive on this
mailing list. For now I'll keep participating on the other lists via
digests.
I'll now try to (start) answer(ing) a few threads that started around the
23rd....
First on spec development processes. I have been directly involved in
the JavaBeans specification, the JavaHelp spec, and the JSP specs.
I've been indirectly involved in several other standards including
ANSI, OMG, and have been around people who have been involved with
several W3C processes [[I have not been involved with IETF]]. I do
not claim that the JCP (java community process) is the ideal process,
but it is the best one I've seen, and the same for everybody that I've
talked to. The process is relatively quick, leads to pretty good
implementable and stable specs, and it is quite balanced and fair to
everybody.
The process can be improved (by design the JCP is under-specified),
and I hope we can do so in the next go-around, where we will have to
find a way that will work well for the open source community. But
developing a spec is not easy, and a good process does not mean one
where everybody feels their needs are matched perfectly. A spec is an
excercise in compromise; anybody who participates in the expert group
should understand that, or will risk being frustrated. There are
several portions in JSP 1.0 and JSP 1.1 that I would have done
differently had I been the only designer and had I been involved with
it from the beginning.
I should not be the one to praise our current spec process, you may
want to talk directly to people who were in the expert group; in the
JSP side, the representatives either have been pretty happy or they
have been not been straight-forward in conversations with me. I've
done my best to satisfy the requirements described above.
On specifics:
| Stefano says:
| Ask
| Eduardo: first time I saw that I had to sign a paper to get into the JCP
| process, I jumped off the chair.
Yes, Stefano complained about the standard NDA that everybody had to
sign to participate in JCP. The intention of the NDA is to protect
the development of the Java platform, and the interests of the
companies and individuals that participate in the process. Without it
we would not have been able to get some companies to participate.
Note that many many companies and individuals, including many active
members in the open source community and in tomcat, have signed that
NDA.
But, as said above, we have to find a version of the JCP that will
work for the open source community and I will work on that.
| ...W3C...
I think you should talk with somebody who has been actively working in
the W3C. Some groups work well, some do not. And, organizationally,
the whole process is less open and accountable than JCP.
Stefano says...
| I'm already invited to partecipate to
| the JCP process of developing Servlet 3.0 and JSP-NG where I'll propose
| Cocoon ideas and solutions for integration with standards
Yep, I invited Stefano and several other people to endorse the "JSR"
(Java Specification Request) for the next version of Servlet and JSP.
Endorsing the JSR just indicates support for the creation of a new
spec, the "call for expert group members" will follow later. My
intention was to craft a first draft of the JSR and circulate it
around several places, including this mailing list, before Christmas
but that has not yet happened. I hope to do that in the next few days.
Ruby says...
| Personally, I would like to see a more open process for the designing and
| implementing of APIs.
I think that most people who participated in the process felt it was
quite fair. In general the hardest partner to deal with is Sun
internal: it is hard to explain to them that indeed we are running a
fair process.
The bottom line to me is that the JCP has worked pretty well, and that
it is flexible enough that it can be made to work better. I'd
encourage you to work through it; I personally pledge to continue to
do my best to use the process to improve the Java Platform.
Hope this helps.
- eduard/o
Re: open processes...
Posted by James Todd <jw...@pacbell.net>.
indeed. i understanding the benefits in keeping the working team small
and focused as the issues at hand are tough enough. the problem is that
little or no time is spent on doc'ing the ongoing thoughts and discussions
which would be invaluable as a spec reference for the implementation
team to "read between the spec lines" so to speak.
if i had my way, the working alias would be open and archived yet only
the working group could post to it. that way, any/all could see the ongoing
thread and the archive would archived for posterity. parallel discussions
could take place on the associated dev aliases (ie tomcat-dev) and the
like. seems like a solid middle ground to me and i believe it'd expedite
things nicely.
later,
- james
Ben Laurie wrote:
> James Todd wrote:
> >
> > "Craig R. McClanahan" wrote:
> >
> > >
> > > * When the first public drafts of a new specification are released, there
> > > is usually no hint of all the back room discussions, and rejected design
> > > choices, that went on before that release occurred. Unfortunately, this
> > > sometimes leaves people wondering "why in the heck did they choose
> > > THAT approach," and can lead to the (usually mistaken) conclusion that
> > > no other alternative was considered.
> >
> > this one ranks pretty high in my book. while it is possible to build an
> > implementation
> > with nothing but a spec in hand it would be extremely helpful to see the
> > formulating thoughts and discussions that went into the decission making process.
>
> Which leads one to wonder why things aren't done in the IETF WG way
> (i.e. working groups are open to all comers). Because the only way you
> are ever going to get access to the thoughts and discussions is by full
> disclosure, and if you are going to do that, you may as well let people
> join in before it is too late.
>
> Cheers,
>
> Ben.
>
> --
> SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
>
> http://www.apache-ssl.org/ben.html
>
> "My grandfather once told me that there are two kinds of people: those
> who work and those who take the credit. He told me to try to be in the
> first group; there was less competition there."
> - Indira Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: open processes...
Posted by Stefano Mazzocchi <st...@apache.org>.
Ben Laurie wrote:
>
> James Todd wrote:
> >
> > "Craig R. McClanahan" wrote:
> >
> > >
> > > * When the first public drafts of a new specification are released, there
> > > is usually no hint of all the back room discussions, and rejected design
> > > choices, that went on before that release occurred. Unfortunately, this
> > > sometimes leaves people wondering "why in the heck did they choose
> > > THAT approach," and can lead to the (usually mistaken) conclusion that
> > > no other alternative was considered.
> >
> > this one ranks pretty high in my book. while it is possible to build an
> > implementation
> > with nothing but a spec in hand it would be extremely helpful to see the
> > formulating thoughts and discussions that went into the decission making process.
>
> Which leads one to wonder why things aren't done in the IETF WG way
> (i.e. working groups are open to all comers). Because the only way you
> are ever going to get access to the thoughts and discussions is by full
> disclosure, and if you are going to do that, you may as well let people
> join in before it is too late.
I could not agree more with this.
I don't like the fact that you have to sign up a non-discosure-agreement
when you enter those JCP committees. The Servlet API Expert Group is the
only one that didn't and, IMO, it showed Sun the power of this. Too bad,
they think specs are company-driven rather than individuals-driven.
I don't want to be unfriendly. I am too impressed by the work done in
Sun and you guys know how much I respect what you have done in the past,
but it's not enough.
Sun is going slowly into the dark side of community unfriendlyness. Can
Sun afford this? I think not.
Sun has moved away from ISO, now is moving away from ECMA. People are
questioning the evolution of the Java platform. I'm one of them.
Does Sun think the best standard is their own? fine, I have no problems
with de-facto standards with no ISO/ECMA labels on top, but let
_everyone_ being involved into it.
Ben is totally right, the IETF process has shown it's ability to stand
evolution, technology challenges, commercial challenges and so forth.
The internet is what it is because of the openess of the IETF process,
no more, no less.
Do you want Java to become the standard platform for programming as much
as the internet has become the standard platform for networking? open up
its evolution processes.
Or Sun will just become the next M$.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: open processes...
Posted by Stefano Mazzocchi <st...@apache.org>.
Ben Laurie wrote:
>
> James Todd wrote:
> >
> > "Craig R. McClanahan" wrote:
> >
> > >
> > > * When the first public drafts of a new specification are released, there
> > > is usually no hint of all the back room discussions, and rejected design
> > > choices, that went on before that release occurred. Unfortunately, this
> > > sometimes leaves people wondering "why in the heck did they choose
> > > THAT approach," and can lead to the (usually mistaken) conclusion that
> > > no other alternative was considered.
> >
> > this one ranks pretty high in my book. while it is possible to build an
> > implementation
> > with nothing but a spec in hand it would be extremely helpful to see the
> > formulating thoughts and discussions that went into the decission making process.
>
> Which leads one to wonder why things aren't done in the IETF WG way
> (i.e. working groups are open to all comers). Because the only way you
> are ever going to get access to the thoughts and discussions is by full
> disclosure, and if you are going to do that, you may as well let people
> join in before it is too late.
I could not agree more with this.
I don't like the fact that you have to sign up a non-discosure-agreement
when you enter those JCP committees. The Servlet API Expert Group is the
only one that didn't and, IMO, it showed Sun the power of this. Too bad,
they think specs are company-driven rather than individuals-driven.
I don't want to be unfriendly. I am too impressed by the work done in
Sun and you guys know how much I respect what you have done in the past,
but it's not enough.
Sun is going slowly into the dark side of community unfriendlyness. Can
Sun afford this? I think not.
Sun has moved away from ISO, now is moving away from ECMA. People are
questioning the evolution of the Java platform. I'm one of them.
DoX-Mozilla-Status: 0009standard is their own? fine, I have no problems
with de-facto standards with no ISO/ECMA labels on top, but let
_everyone_ being involved into it.
Ben is totally right, the IETF process has shown it's ability to stand
evolution, technology challenges, commercial challenges and so forth.
The internet is what it is because of the openess of the IETF process,
no more, no less.
Do you want Java to become the standard platform for programming as much
as the internet has become the standard platform for networking? open up
its evolution processes.
Or Sun will just become the next M$.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: open processes...
Posted by Ben Laurie <be...@algroup.co.uk>.
James Todd wrote:
>
> "Craig R. McClanahan" wrote:
>
> >
> > * When the first public drafts of a new specification are released, there
> > is usually no hint of all the back room discussions, and rejected design
> > choices, that went on before that release occurred. Unfortunately, this
> > sometimes leaves people wondering "why in the heck did they choose
> > THAT approach," and can lead to the (usually mistaken) conclusion that
> > no other alternative was considered.
>
> this one ranks pretty high in my book. while it is possible to build an
> implementation
> with nothing but a spec in hand it would be extremely helpful to see the
> formulating thoughts and discussions that went into the decission making process.
Which leads one to wonder why things aren't done in the IETF WG way
(i.e. working groups are open to all comers). Because the only way you
are ever going to get access to the thoughts and discussions is by full
disclosure, and if you are going to do that, you may as well let people
join in before it is too late.
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: open processes...
Posted by James Todd <jw...@pacbell.net>.
"Craig R. McClanahan" wrote:
>
> * When the first public drafts of a new specification are released, there
> is usually no hint of all the back room discussions, and rejected design
> choices, that went on before that release occurred. Unfortunately, this
> sometimes leaves people wondering "why in the heck did they choose
> THAT approach," and can lead to the (usually mistaken) conclusion that
> no other alternative was considered.
this one ranks pretty high in my book. while it is possible to build an
implementation
with nothing but a spec in hand it would be extremely helpful to see the
formulating thoughts and discussions that went into the decission making process.
- james
Re: open processes...
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
Eduardo Pelegri-Llopart wrote:
>
> I should not be the one to praise our current spec process, you may
> want to talk directly to people who were in the expert group; in the
> JSP side, the representatives either have been pretty happy or they
> have been not been straight-forward in conversations with me. I've
> done my best to satisfy the requirements described above.
>
I have been on the expert review group for both JSP 1.0/1.1 and servlet 2.2,
and was satisfied that my concerns were heard. A couple of areas we might
think about improving for the future include:
* In some cases, it appears that "time to market" issues drove the
completion date for specs, instead of "functional completeness".
Sometimes, this meant that features which were very desireable
(my favorite missing one is application start/stop events, insert
your favorite here ...) could not be addressed simply because of
the timing considerations.
This is a different kind of discipline for most open source developers,
but is old hat for people who get paid to design and build non-trivial
systems. I expect there will be some creative tension between dates
and functionality in the next go-arounds -- but open source projects
that expect to produce software products taken seriously in the
marketplace need to learn how important time to market (and even
more than that, a reasonably predictable schedule) really is.
* When the first public drafts of a new specification are released, there
is usually no hint of all the back room discussions, and rejected design
choices, that went on before that release occurred. Unfortunately, this
sometimes leaves people wondering "why in the heck did they choose
THAT approach," and can lead to the (usually mistaken) conclusion that
no other alternative was considered.
IMHO, the JDBC 1.0 and 2.0 specs did a nice job trying to allay some of
these concerns by describing the rejected or changed design choices
that were made. The EJB specs did something useful in a different direction
-- they described the goals ***and the non-goals*** that the technology was
designed to address. Something like this for servlets, for example, would
go a long way towards helping decide whether some sort of servlet chaining,
or an Interceptor architecture at the application level, or (name your
favorite
enhancement here) really belongs or not. If it doesn't belong, then any
discussion about ***how*** to do it becomes irrelevant.
* The public "spec feedback" EMAIL address appears to feel, to most
contributors, like a black hole. (Even the expert groups don't necessarily
see the suggestions that come in that way). It seems to me that some
mechanism to accumulate and distribute the suggestions (and demonstrate
to the suggesters that they were at least listened to) would go a long ways
towards reducing the ***perceived*** closed-ness of the JCP process.
As Eduardo says, spec development is an exercize of the art of compromise.
Overall, I've been pretty impressed with the quality of the Java API
specifications; but we should strive to improve the quality and quantity of the
information that is fed in to the development process, so we can also improve
the quality of what comes out. One of the easiest ways to do that is to make
it clear that suggestions are being listened to, even if they are not necessary
acted upon in the way that the suggester might have proposed.
Craig McClanahan