Re: drafts of JSRs for JSP & Servlet

[Jason Hunter <jh...@acm.org>]

Eduardo Pelegri-Llopart wrote:
> 
> And, on that topic, attached are the 2 drafts of the JSRs that we
> expect to submit to the JCP on Monday.  The JSRs are intentionally
> pretty vague and really most things can be changed by the expert
> group.  At this point, the intention of the JSR is just to say: "we
> want to start working to make things like this happen". 

Eduardo, you didn't attach the JSR drafts.  I'm sure people would be
appreciative if you could do that.  Because you obviously intended to
release the JSRs publicly, I feel it's OK for me to comment here on some
of what I know about the JSRs -- specifically the fact that JSR-051
proposes that the servlet and JSP specifications be developed together.

I want to make sure that we don't see too tight a coupling between the
Servlet and JSP specifications.  They should always be distributed as
separate PDF files with separate documentation and separate licensee
agreements.

The servlet specification should remain agnostic when it comes to
technologies built upon it such as JSP.  When there's a one-way
dependency (as there is with JSP on servlets) it's customary to have 
the standalone technology remain standalone.  This servlet/JSP combined
development strikes me like doing combined development with the TCP/IP
and HTTP specifications.  Sure, there could be some benefits from a
tighter integration, but TCP/IP shouldn't be tightly coupled to HTTP,
and neither should servlets be tightly coupled to JSP.  Of course the
respective servlet and JSP spec leads should talk to each other, but do
we really need officially-endorsed combined development?

Many people will want to use servlets without using JSP.  More
importantly, many servers will want to implement servlets without
implementing JSP.  If there's a combined spec, how can they readily 
know what's legally required and what's not if there's just one
specification?

So my point is that servlets should remain separate from JSP.  Separate
specification files, documentation, everything.  Perhaps this can be
accomplished with the Servlet and JSP specifications in the same JSR,
but wouldn't it be better for them to start separate if they're to end
separate?

-jh-

Re: drafts of JSRs for JSP & Servlet

[Jason Hunter <jh...@acm.org>]

Eduardo Pelegri-Llopart wrote:
> We hear your concerns
> and we hope you will help us to keep the two specs honest, or just 
> the servlet if you want to only participate on that one.
> 
> thanks for speaking up, and feel free to continue this exchange if 
> you want.

Thanks, Eduardo.  Your responses have helped allay my concerns.  :-)

-jh-

Re: drafts of JSRs for JSP & Servlet

[Eduardo Pelegri-Llopart <Ed...@eng.sun.com>]

Jason Hunter wrote:
> I dug through all my mail and didn't find the second posting.  Perhaps
> it just got eaten on my system.  (If someone out there didn't get the
> second post either, please write so Eduardo can repost.)

Yes, please.

> > The intention is that the servlet spec can be used independently of
> > the jsp spec.
> 
> Excellent.  I had a feeling that was your intent, and am glad to hear
> you verify.
> 
> Thanks for giving specific reasons for a combined expert group.
> Frankly, I still would rather see them separate.

> Separation would
> provide a balance of power that would ensure the Servlet API wasn't
> overly influenced by JSP requirements.

I agree, there is a real benefit in having an individual that "owns" a
piece;  it must be a territorial remain from our primate ancestry :-). 
That is part of the reason why Danny is there.  Other reasons being his
expertise (in particular with the J2EE RI), his brain, and his cycles
:-)

> Sun has historically believed
> in this sort of separation.  That's why Sun set up a "Chinese wall"
> between the servlet platform and the Java Web Server product.

Just to clarify, that sort of chinese wall still exists; if anything
bigger than in the past.  It is a wall between the Java Platform group
and Sun's product teams and we take it *very* seriously.  I was not a
JWS person, but, if you ask me, JWS lived in a very strange space,
within the Java Platform group but trying to make $$s as a product.  Sun
product teams are now farther away from the spec groups, which makes
defining the wall a bit easier.

Having one JSR for two specs is not common, but I think it is the best
for this case.  The JCP process is pretty new, so I can't point to
another example of doing this, but I can point to several examples of
JSRs that are sharing the same expert lead.  On the other side, we are
splitting the standard library for JSP into a separate JSR instead of
folding it into the original JSR because we think it is best (reasons
explained in the JSR itself).  I like JCP because it gives us
flexibility to do this type of adjustements to the process.

> It took
> more communication effort, but was the Right Thing to do.

In my experience, there are plus and minuses for many organizational
structures and there is a bit of pendulum effect: this time we will
emphasize this, next time we will emphasize that.  We hear your concerns
and we hope you will help us to keep the two specs honest, or just the
servlet if you want to only participate on that one.

thanks for speaking up, and feel free to continue this exchange if you
want.

	- eduard/o

> 
> -jh-

Re: drafts of JSRs for JSP & Servlet

[Jason Hunter <jh...@acm.org>]

Eduardo Pelegri-Llopart wrote:
> 
> You are right, Jason, my original mail did not include the draft,
> but as soon as I found out about that, I followed up with a posting
> with the drafts.  
> Would be happy to send those again to this forum if there was
> any problem with my second posting, but I do not want to use bandwidth
> unnecesarily.

I dug through all my mail and didn't find the second posting.  Perhaps
it just got eaten on my system.  (If someone out there didn't get the
second post either, please write so Eduardo can repost.)

> On your specific concerns about the binding between Servlet and JSP
> specifications:
> 
> The intention is that the servlet spec can be used independently of
> the jsp spec.  

Excellent.  I had a feeling that was your intent, and am glad to hear
you verify.

Thanks for giving specific reasons for a combined expert group. 
Frankly, I still would rather see them separate.  Separation would
provide a balance of power that would ensure the Servlet API wasn't
overly influenced by JSP requirements.  Sun has historically believed 
in this sort of separation.  That's why Sun set up a "Chinese wall"
between the servlet platform and the Java Web Server product.  It took
more communication effort, but was the Right Thing to do.

-jh-

Re: drafts of JSRs for JSP & Servlet

[Eduardo Pelegri-Llopart <Ed...@eng.sun.com>]

You are right, Jason, my original mail did not include the draft, but as
soon as I found out about that, I followed up with a posting with the
drafts.  Would be happy to send those again to this forum if there was
any problem with my second posting, but I do not want to use bandwidth
unnecesarily.

On your specific concerns about the binding between Servlet and JSP
specifications:

The intention is that the servlet spec can be used independently of the
jsp spec.  We really want that, and we attempted to capture that very
clearly in the JSR.  For example, it talks about 2 specs all along, and
the JSR spells that the servlet spec can be used without the JSP spell
as soon as it is possible in the document.  It is the intention that
Servlet will be agnostic for JSP, even more than it is today.

I don't think the JSR should get into the details of how the
specifications should be packaged, distributed, or licensed, as long as
the above goal is satisfied.  In particular, those goals would *NOT* be
met if there was a single license that allow people to implement JSP and
Servlet ONLY when done together, and they would NOT be met if people had
to pick and choose from a single document which pieces are Servlet only
and which ones are JSP.

I think we have the same goals with Servlet.  And to help those, we have
asked Danny to be the "Servlet man" in the expert group.

There are several reasons to run both specs from the same expert group.

* They are very inter-related, and there would be big overlaps among the
groups; having a single group simplifies the communication so there are
no gaps.  We had a few last time and we want to avoid that.

* An important goal of the servlet.next spec is to support jsp.next.

* Running an expert group is a lot of work; it pays off to share some of
that cost.

* Running a JCP expert group requires expertise; we don't have that many
people that know how to do that.  My experience is that the way to best
way to learn how to do it is to be part of it first, that is how I did
it (JavaBeans), and that is what we are doing with Anil and Danny.

I hope this alleviates some of your concerns,

	- eduard/o


Jason Hunter wrote:
> 
> Eduardo Pelegri-Llopart wrote:
> >
> > And, on that topic, attached are the 2 drafts of the JSRs that we
> > expect to submit to the JCP on Monday.  The JSRs are intentionally
> > pretty vague and really most things can be changed by the expert
> > group.  At this point, the intention of the JSR is just to say: "we
> > want to start working to make things like this happen".
> 
> Eduardo, you didn't attach the JSR drafts.  I'm sure people would be
> appreciative if you could do that.  Because you obviously intended to
> release the JSRs publicly, I feel it's OK for me to comment here on some
> of what I know about the JSRs -- specifically the fact that JSR-051
> proposes that the servlet and JSP specifications be developed together.
> 
> I want to make sure that we don't see too tight a coupling between the
> Servlet and JSP specifications.  They should always be distributed as
> separate PDF files with separate documentation and separate licensee
> agreements.
> 
> The servlet specification should remain agnostic when it comes to
> technologies built upon it such as JSP.  When there's a one-way
> dependency (as there is with JSP on servlets) it's customary to have
> the standalone technology remain standalone.  This servlet/JSP combined
> development strikes me like doing combined development with the TCP/IP
> and HTTP specifications.  Sure, there could be some benefits from a
> tighter integration, but TCP/IP shouldn't be tightly coupled to HTTP,
> and neither should servlets be tightly coupled to JSP.  Of course the
> respective servlet and JSP spec leads should talk to each other, but do
> we really need officially-endorsed combined development?
> 
> Many people will want to use servlets without using JSP.  More
> importantly, many servers will want to implement servlets without
> implementing JSP.  If there's a combined spec, how can they readily
> know what's legally required and what's not if there's just one
> specification?
> 
> So my point is that servlets should remain separate from JSP.  Separate
> specification files, documentation, everything.  Perhaps this can be
> accomplished with the Servlet and JSP specifications in the same JSR,
> but wouldn't it be better for them to start separate if they're to end
> separate?
> 
> -jh-