Good point.
And I have to add that having a single RI has contributed to EE
moving slow in the past. The vendors would wait for the
Spec/TCK/RI to stabilize before moving on with their own
implementation. It was also a market reality that customers moved
slow, too, when adopting the latest platform.
Having multiple implementations and no RI implicitly forces the
implementors to deliver faster, too. So that's probably a good
thing, as long as there many willing implementors. Or as Rich
pointed out, in certain areas a single implementation might
suffice even if we don't call it an RI.
Again, in the absence of RIs there has to be a way for
interoperability testing. Maybe it would be enough to demonstrate
interop with any other implementation.
Cheers
/Dimitris
Red Hat JBoss EAP/WildFly
On 13/10/2017 15:11, Kevin Sutter wrote:
The Eclipse MicroProfile project is
not
producing RIs. We are producing Specs, APIs, and TCKs. No RIs.
We want each vendor to produce their own implementation of the
spec
and then verify it's "correctness" by running the TCK. So,
in essence, we have multiple "reference implementations".
Of course, this makes writing a
TCK
a bit more difficult. Without a specific RI to test against,
writing
a runnable TCK is tricky. In many cases, the various vendors
are
implementing the feature while the spec is being developed. Or,
maybe
there are some "sample implementations" being developed to prove
out the spec and the TCK. So far, it's been working out for us.
Just a data point that RIs are
not an
absolute requirement.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
ee4j-community-bounces@xxxxxxxxxxx wrote on
10/13/2017
07:38:12 AM:
> From: Dimitris Andreadis <dandread@xxxxxxxxxx>
> To: ee4j-community@xxxxxxxxxxx
> Date: 10/13/2017 07:38 AM
> Subject: Re: [ee4j-community] Eclipse
Jetty and
EE4J
> Sent by:
ee4j-community-bounces@xxxxxxxxxxx
>
> Sure. But that should mean that the spec needs to be
revised to be
> more accurate. While implementing the specs there can/has
been cases
> where either the TCK or even the RI is challenged for not
adhering
> to the spec.
> BTW, I do find RIs useful.
> On 13/10/2017 14:21, Guillermo González de
Agüero
wrote:
> In case of ambiguous wording on specs,
usually
RIs have been
> referenced as "the truth", like if they were part of the
spec
> itself. I guess Ben refers to that.
>
> Regards,
>
> Guillermo González de Agüero.
>
> El vie., 13 oct. 2017 a las 13:44, Dimitris Andreadis
(<dandread@xxxxxxxxxx
> >) escribió:
> 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 bea 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 keycomponents
> >>> 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
>
> _______________________________________________
> 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://urldefense.proofpoint.com/v2/url?
>
u=https-3A__dev.eclipse.org_mailman_listinfo_ee4j-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-
>
siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=2glpCratNhIH_D2ZXjVXIJcwzVaAOhEm1LxRzuWltgk&s=6nlMBhP8D8OxDwMmQqznwV3r5CCPflqHSXAkHiz3lXI&e=
_______________________________________________
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
|