Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Eclipse Jetty and EE4J

How you define "significantly elevated"? I'm obviously biased, but the only objective differentiator is having to implement the spec first.

/Dimitris

Dimitris Andreadis
Senior Engineering Manager
Red Hat JBoss EAP/WildFly

On 13/10/2017 13:31, Ben Evans wrote:
I see it more as a question of whether the RI is significantly
elevated among a number of open source implementations or regarded
more as "first among equals".

Personally, I would tend towards the point of view that having an RI
is good in most circumstances, but that it should be thought of more
as the latter than the former.

Thanks,

Ben

On Fri, Oct 13, 2017 at 3:14 PM, Dimitris Andreadis <dandread@xxxxxxxxxx> wrote:
The absence of an RI is an interesting approach, i.e. if the Spec is
complete enough to not have to look into the RI to understand
under-specified aspects.

How about interop testing that is now performed against the RI? Should you
be able to pick any other opernsource implementation and test against it, to
claim compliance?

/Dimitris

Dimitris Andreadis
Senior Engineering Manager
Red Hat JBoss EAP/WildFly

On 13/10/2017 03:42, Greg Wilkins wrote:


On 13 October 2017 at 11:31, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
This is interesting indeed. One of the things I will admit I was thinking
about is whether Jetty could replace Grizzly as the Servlet RI and the Jetty
folks lead Servlet in the future. Indeed I was wondering the same thing in
the Servlet 4 time frame. Only a pipe dream perhaps?


While we certainly wish to be part of future the servlet spec into the
future, I'm not sure that I would advocate a long term Jetty "leadership"
any more than a Glassfish, Tomcat or Undertow one.

Whatever the governance structure of the spec groups are, that should not
provide any significant power to set the agenda nor technical direction to
an individual or single implementer.    The goals and agenda for driving the
spec forward should come from the community and the technical solutions
should be determined collaboratively between implementers.  So perhaps
"convener" is a better name than "leader" and as such it could be a rotating
role to share the effort around?

As for RI's, I'm not a big fan of them, as they facilitate lazy incomplete
specs.   Any behaviour that is not explicitly described in specification
and/or tests should be deemed undefined rather than follow one specific
implementation that may be written to meet
effort/commercial/scaling/performance criteria that cannot be applied
generally to all implementations.

Jetty has a long history and firm focus on our target market(s), which is
often apparent if you look in the gaps between that parts fixed by
specification.  It is unlikely that our history and/or markets are
appropriate to be a reference for other implementations that share neither
that history and/or focus.    I certainly would not like to be constrained
in the development of jetty so that we could not change unspecified
behaviour for fear of changing the specification reference for all others!

I would much rather see multiple implementations developed during the
specification process (as per the IETF working code mantra) together with a
collaborative test suite.    Once a specification version is final, no
implementation should be more special than any other.     Portability issues
should be addressed by refinement of the specification and collaborative
development of new tests.


regards



Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Greg Wilkins <gregw@xxxxxxxxxxx>
Date: 10/12/17 7:23 PM (GMT-05:00)
To: ee4j-community@xxxxxxxxxxx
Subject: [ee4j-community] Eclipse Jetty and EE4J


The Eclipse Jetty team would like to extend a welcome to the EE4J project
and the new contributors it will bring to the eclipse foundation.   Eclipse
has been a good home for the Jetty project and has struct a good balance
between the sometimes competing concerns of guidance, structure, support,
autonomy and flexibility.

We are please to see an opening up of the specification processes and TCKs
and we very much wish to play a part in the ongoing development/innovation
of the Servlet specification and it interplay with the other key components
within the EE space.

Our belief is that EE needs to develop into a more component oriented
architecture where individual technologies can be more stand alone and/or
plug/play rather than be built only as part of monolithic whole.     The
Jetty project already uses/provides components from/to other contributors to
the EE ecosystem and we would like to see a spec and test environment
develop that would facilitate further such collaboration, so we can all
concentrate of improving and innovating within our core features.

We look forward to see how the governance within and between the EE
specifications is developed and hope to play a part in both the formulation
of that and the execution.

regards

--
Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com

_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community



--
Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com


_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community



_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community

_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community



Back to the top