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.
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
_______________________________________________
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
