Re: [rt-pmc] RT projects and standards

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

On 12/1/2010 11:23 AM, Jeff McAffer wrote:
> > 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
> Yup that is a good start for OSGi-related specs.  We'll need to see information from other projects as well to see what their interests/concerns are around other specs/standards.  So the thinking was that you start a wiki page at eclipse.org for the ECF stuff.  Then other project folks can add their info related to whatever specs they care about.  Once we see a good cross-section of info we can start talking about exact form.

As mentioned before my personal resources are limited, so I don't know 
when I'll be able to do this.


> Question: are you only interested in standards implementations or is it interesting to know about standards "use"? That is, ECF implements the remote services spec but it also adapts or enables ZeroConf, XMPP, ...  Seems like understand this would be interesting from a consumer point of view.

This information (about what standard protocols we use/support/have 
implementations of) would probably be useful to some ECF consumers...and 
would-be consumers.

> ECF feels like an ideal prototype project for this kind of info.

ECF is indeed both an implementer of standards (OSGi remote 
services/Remote Services Admin) and a consumer of standards (e.g. OSGi 
framework...as well as a number of protocol standards...e.g:  JMS, 
zeroconf, slp, dnssd, xmpp, http/https, etc).


> > 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.
> FWIW I do ping them on the topic (and others) from time to time.

Well, I can tell you for sure that it's still largely a matter for the 
individual projects/project leads to deal with.


> > AFAIK these aren't related to anything to do with standards, but that's a side issue.
> Project collaboration issues are quite separate from standards use/implementation.  If I understood your general goals it was to make it easier for people to understand and consume what the projects produce.  The cited collaborations are focused on exactly that.  IMHO there is nothing sacred about standards when it comes to collaboration.

I disagree with this...as I think that collaboration/coordinated 
multi-project action may be 'nice-to-have' in general (although I see it 
as more important than that for organization-wide health), but when it 
comes to standards it's closer to essential IMHO...to avoid 
balkanization, re-work/re-implementation, and all those inefficiencies 
that reduce or slow standards adoption and usage (which is the only 
thing that will make the standard relevant).


> > > 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.
> If asked I would have said that that matches the current "policy".  Projects are encouraged to collaborate.  That means, don't ignore each other.  However, what is not said in your statement or the current policy is what happens when projects choose different paths.  That is, MUST projects collaborate?  It'll be very hard to drive that model.

IMHO having it be 'hard' (under current pmc approach) doesn't make it 
less important....for projects or their consumers/community.

Scott