www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: Handling Innovation and Producing an RI
Date Tue, 19 Feb 2008 18:00:33 GMT

On Feb 19, 2008, at 12:54 PM, Endre Stølsvik wrote:

> Geir Magnusson Jr. wrote:
>> On Feb 19, 2008, at 9:23 AM, Endre Stølsvik wrote:
>>> kelvin goodson wrote:
>>>> I would like to understand how Apache projects which develop JSR  
>>>> reference implementations (RI) handle the apparent conflict  
>>>> between developing an RI,  and having a project that innovates  
>>>> outside the specification.
>>>
>>> Very good question. It seems a bit to me like Apache finds it  
>>> flattering that RIs are developed (or rather, "dumped") here,  
>>> while there is no actual standard, formal or de-facto, of how to  
>>> handle the obvious conflict you describe.
>> Where is the conflict?
>
> That a RI should be as lean and simple and obvious and cleanly coded  
> as possible - ONLY demonstrating the exact specification* so that it  
> is easy to compare the specification wording to the implementation -  
> and so that actual implementations can look in the code and use that  
> as a addendum to the specification, "aha, so that's what they mean".

There's no requirement of that.

>
>  Note that "clean" here might not be the correct word - all code  
> should be clean, but RIs should be clean as in "simple", in the  
> "cheap" meaning of the word. Just do what is needed, and do that  
> efficient, not going about having nice extension points etc.
>
> On the opposite side, a "production product" should have lots of  
> features, lots of configurability, add-ons and -ins, modular, have  
> deep monitoring capabilities, JMX/management consoles, be  
> embeddable .. and what have you.
>
> This is the same distinction between writing code for an instruction  
> manual, a programming book or an article for a blog entry, as  
> opposed to making a comprehensive solution suitable and tailorable  
> to thousands of settings and situations.
>
> Seriously, isn't this exceptionally obvious? What hidden message are  
> you trying to convey, Geir?

My point is that there's no requirement that an RI do that.  It's  
nice, but not required.  We've had the codebase for servlet RI in  
Tomcat for years.  Would you call that "clean"?

If a project implementing the RI of a JSR wishes to do it that way -  
have a clean "core" that is the RI, and then layer on features -  
that's cool.

I think it's really up to the implementing community - as long as it  
passes the TCK and is the implementation offered by the spec lead as  
proof of implementability, it's the RI.

geir


>
>
> Endre.
>
> *) This obviously didn't go for Pluto, which was convoluted, badly  
> coded, dirty sticky ugly spaghetti - but it should be the ideal.


Mime
View raw message