tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eduardo Pelegri-Llopart <pele...@eng.sun.com>
Subject re: open processes...
Date Tue, 04 Jan 2000 21:39:32 GMT
Thanks for the suggestions, Craig.  If you don't mind, I'll send your
comments to the JSP & Servlet expert groups as a primer to get further
suggestions on how to improve the process.  Anybody else who wants to
send suggestions please send them to me, either privately or
publically.

Individual comments below.

	- eduard/o

| From: "Craig R. McClanahan" <cmcclanahan@mytownnet.com>
| Subject: Re: open processes...
| Message-Id: <38714759.9108591F@mytownnet.com>
| 
| 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".
| .....

Servlet 2.2/JSP 1.1 had the additional constraint that we were in the
same train as J2EE 1.2, and we didn't have much leeway.

I think/hope we will have an easier time with the "dot.next" specs. 

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

Agreed.  Another issue perhaps worth pointing out is backwards
compatibility.

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

Good point, we can certainly do much better.  One issue is how to
organize the docs to combine:

	- the normative pieces,
	- goals,
	- non-goals,
	- commentary on the technical implications of the normative
	pieces, including some implementation issues.
	- commentary on the expected usage,
	- commentary on design choices

It is hard to put everything into the same document.  Maybe we can try
different things.  The EJB editors used some formating conventions to
differentiate between normative and non-normative.  The annotated XML
spec does, IMO, a great job.

In the case of JSP 1.1, we circulated a number of goals/non-goals &
design choices early on, before Craig joined, which were very helpful
in achieving convergence, but we never spent the time to create public
versions of those documents.

I expect that exploring goals/non-goals will be the first topic of
discussion for the expert group.

| * The public "spec feedback" EMAIL address appears to feel, to most
|   contributors, like a black hole.

That one is mostly my fault.  I try to reply to the messages but
sometimes they just pile in my inbox due to lack of cycles.  This we
can do much better.

|   (Even the expert groups don't
|   necessarily see the suggestions that come in that way).

That we can do better.  Some feedback is not intended to be shared
with all the members of the expert group but only with the expert
lead, but much other feedback is and we currently have no mechanism to
differentiate between those.  I have tried something on the JSP 1.1
side with the concept of the TFAQ mailing list but it needs
fine-tuning.

| Craig McClanahan

Thanks for the comments, and send any others you may have.

	- eduard/o

Mime
View raw message