tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <cmcclana...@mytownnet.com>
Subject Re: open processes...
Date Tue, 04 Jan 2000 01:05:30 GMT
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



Mime
View raw message