[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [rt-pmc] RT projects and standards
|
On 12/1/2010 10:22 AM, Jeff McAffer wrote:
1) Difficulty of consuming standards from RT projects. Here are what I perceive as some consumer problems with RT wrt standards...I'm sure other RT project leads have others.
a) How do I find out what OSGi standards are implemented by RT projects?
b) How do I get implementations from RT projects of standards x, y, z (or parts of standard)
c) Why does project x *not* implement relevant standard y
d) Is standard x implemented by multiple RT projects? If so, why?
e) What versions of which standards (e.g. OSGi 4.2, 4.3, etc) are implemented by which project?
f) What is the status of the standards impls on RT projects that are engaged in implementing standards?
Exposing our many standards interactions/implementations would be a good thing. Perhaps a wiki page table (e.g., http://wiki.eclipse.org/RT/Standards) could capture a, b, e and f. c and d could be captured in a "discussion" section on that same page. Note that we have way more than just OSGi standards at play here.
Can you take a stab at contributing/formatting this information wrt ECF?
Well, I guess this gives a start (although it's a little out of
date...i.e. doesn't have anything about ECF's ongoing RSA implementation
yet): http://en.wikipedia.org/wiki/OSGi_Specification_Implementations
2) TCK access for projects. For EF projects to fully implement various standards...and verify for their consumers that those standards are complied with...it's necessary for projects to have access to the TCK associated with the standard (if one is available). In too many cases, this is very difficult.
We discussed this a bit in the call. The EMO already engages with the standards bodies to get the access required. In the case of OSGi specs it is an EMO/IP team topic right now as there seems to be some issue with the OSGi license. Its not clear what more we as the projects can do except for make more noise.
It might help if the rt-pmc made the appropriate noises once or
twice...on behalf of all RT projects...rather than the individual
projects having to make noise (and waste a lot of time and effort doing
so) repeatedly and individually.
3) RT projects working together on relevant standards. I assert that 'encouragement' of rt projects to work collaboratively on standards hasn't, doesn't, and perhaps will never work.
I agree that encouragement does not always work but it certainly can work. RT has a number of great examples of projects working together (on standards or otherwise). Virgo/Jetty, RAP/Riena, Virgo/RAP, EclipseLink/EMF/Teneo, Jetty/Equinox, ...
AFAIK these aren't related to anything to do with standards, but that's
a side issue.
Can you be more concrete on what your ideal policy would be in this area?
My ideal policy: that RT projects that are doing the same thing
technically (for ECF it's remote services and RSA) don't actively or
passively ignore other RT project's work (or other standards work),
reimplement the same specs for no other reason than nih and/or
commercial, product, control, ignorance, or personal concerns. I know
such 'management' is not what the pmc, rt projects, or EF has done
before...but I suppose that's the point.
Scott
