Personally, I don't understand the attitude. You (James) have been very clear as to
the respective purposes of the lists and I think, from both a servlet developer's and
software design analyst's views, the demarcation is not only natural, but required. I
come here to get quick answers to technical problems - I do not want to wade through a
sea of specification comments on future releases; I go to java.sun if I want to read
the latest news on the specification (or ask James directly :-) ).
I think this thread has had merits, but it's time to put it to sleep. Let's get on
with the business of writing code for today's apps.
Of course, this is just my opinion; I could be wrong (w/ apologies to Dennis Miller)
~mark
>>> James Duncan Davidson <[EMAIL PROTECTED]> 7/18/99 09:57:06 PM >>>
> As a servlet developer that's invested a lot in servlet technology I'm here
> to tell you that statements like this make me froth at the mouth. I expect
> Sun to seriously listen to the opinions of the developers on this list.
We do. But please, read the JCP documentation. The feedback for the
specification is an audited process. Each and every piece of feedback
that comes in gets stored forever somewhere. Every piece of it also goes
directly into my INBOX and is not filtered out to the list mailbox where
it gets skimmed whenever time permits. Messages to this list isn't
getting stored as part of that process, nor will it.
This list is chartered as a list where users can get together and help
each other. 90%+ of the messages here are messages messages not directly
related to the spec. -- and well they should be. Most people want to get
things done with servlets as they are currently implemented. They are
discussing how to make JSDK work better, how to use servlets for
particular applications, etc. With no separation between this general
(and very useful) chatter from direct specification feedback, it makes
things very hard if not impossible to audit. This compromises the
guarantees, as laid out in our documents -- the JCP and the previous
spec development document -- that are made by Sun as to how
specifications are developed.
You may be assuming that the specification group reads each and every
email to this list with the attention that is given to feedback that
comes into the official alias. Unfortunately this is not the case. Mail
to this list gets read and possibly responded to. Mail to the feedback
alias gets printed out, redlined, carried on planes, etc. By using the
feedback alias you *guarantee* that your comments get carefully read and
evaluated. By posting here, they probably will get read, but maybe they
won't get the evaluation and care that they deserve (and which they
*will* get by being sent to the feedback alias). Do you want to run that
risk?
You may ask why can't we read each and every post to this list with the
attention given to feedback. The answer is simple volume and time. I'm
already working 12 hour days and sometimes more. There's well over 500
messages a day that hit my email account and get filtered out into
various placed to be dealt with (Sun is a very email centric culture, it
makes the amount of mail on the open net look positively tame -- add
high volume lists to the equation and things get loaded down fast). I
can safely say that most people here on the servlet and JSP teams are in
the same boat.
Also, specification email is *more* important than any other kind of
servlet related email. It comes before implementation email about the
JSDK, it comes before everything else servlet related. This is because
not only do we have an implementation of the servlet API (which is the
reference), but there are servlet engines built by many other vendors. A
JSDK problem affects JSDK users. A spec comment affects the entire
servlet community.
Finally, you really don't want anybody here deciding what is official
feedback and isn't. *YOU* should be the one that controls whether your
feedback is required reading or not. And you can by using the alias.
I'm truly sorry that my attempts to clarify this made you "froth at the
mouth" -- and yes, most everything that gets discussed here and that I
see impacts the specification one way or another. However, I can't
guarantee that it will get the same attention here as it would in
feedback. I can't guarantee that we'll *see* it here and act
appropriately or with the level of detail that should be expected for
spec feedback. This is why I'm *so* adamant about using the feedback
alias. I'm also adamant about this as I want you to know the right way
of commenting on the specification. I want everyone to know the rules of
the game.
It's rather ironic that by trying to explain the rules of the game, I
pissed you (and evidently others) off. I admit, I may not have done the
best job at it, but it seems that the path of least resistance would
have been just to keep my mouth shut, try to determine what were useful
pieces of feedback, and pick them up while running the risk of dropping
something important on the floor. However, I don't think that would have
been very fair of me to not tell you the right way of doing things.
<sigh>
.duncan
--
James Davidson
[EMAIL PROTECTED] http://java.sun.com/products/servlet
[EMAIL PROTECTED] http://jakarta.apache.org
!try; do() PGP:0x7D776205
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
