Re: [ecf-dev] AW: jSLP will be donate to the directoy project at apache.

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Jeff,

Jeff McAffer wrote:

This is great news either way. 

I agree.  I just want to say publicly how thrilled I am that both Markus and Jan have agreed to participate in ECF.  Having access and coordination with the expertise and codebases for jSLP (discovery) and r-OSGi (remoteservices) is very exciting.

Having the function available is the most interesting part.  Having it at Eclipse is certainly more convenient but then I'm sure the Apache folks would say the same about having it at Apache.  Running the legal system here at Eclipse may take some time but at least for incubation it is not a big deal.  Some additional topics/thoughts

- What is the timeline for the SLP implementation?  That is, will there be something in place/released by Ganymede?

There are two components to this answer:

jSLP is at RC1:  http://jslp.sourceforge.net/ and Jan and Markus have conveyed to us that there is small amount of work to do to get it to final.  We obviously need to get it to final before we 1) submit a CQ to IPZilla and 2) put into Orbit.  I'll let Jan give details about his and Markus' schedule on this, but I got the impression it could be at final by ~end of Nov without any trouble.

The ECF discovery provider based upon jSLP (by Markus Kuppe) is already done.  There will likely be only trivial changes to it in response to jSLP getting to final.  We've currently got it at the ecf1.osuosl.org CVS server, where we have other stuff in incubation.  When Markus is approved as committer for ECF (should happen this week), then we'll submit a CQ for it as an EPL contribution get it through the process that way.

I'm hopeful/expecting that both of these will be all the way through the IP approval process and a part of the ECF distribution well before EclipseCon 2008.  For me, it's a given for ECF 2.0/Ganymede.

- For these things we need to look at how to consume intermediate results. I'm not sure how this would work given the IP process.  We could likely get "milestones" from Apache and run them through IP for initial license review.   Code from Apache generally goes through pretty fast.

- ECF having graduated is no longer entitled to parallel IP consideration.   Given the nature of ECF (implementing new protocols etc) this is something we should look at addressing.

Yes.  We have been maintaining an 'ECF Extras' site at the OSU Open Source Lab for bundles which cannot be under EPL (e.g. yahoo provider, which is based upon GPL code), and for bundles that are 'not ready for submission to EF CQ process' (like the ECF SCP provider by Markus...since it's dependent upon jSLP).  We have a separate build for these bundles, and a separate CVS server and web server...i.e. http://ecf1.osuosl.org (anonymous CVS given on the web page).

I suppose we could also/instead take the tack that other projects are taking on this, and have an 'ECF Incubator' project.  But I've sort of been waiting to see how the organizational/process discussions go on this, because obviously the 'parallel incubators' approach creates its own set of problems as we begin to approach all projects having a parallel incubator project...

Scott

Jeff

"Rellermeyer  Jan Simon" <rellermeyer@xxxxxxxxxxx>
Sent by: ecf-dev-bounces@xxxxxxxxxxx

10/24/2007 06:10 PM

Please respond to
"Eclipse Communication Framework \(ECF\) developer mailing list."        <ecf-dev@xxxxxxxxxxx>

To	"Eclipse Communication Framework (ECF) developer mailing list." <ecf-dev@xxxxxxxxxxx>
cc
Subject	[ecf-dev] AW: jSLP will be donate to the directoy project at        apache.org

Yes, let me clearify this a bit. My intention is and was to donate my project to where they are most helpful (with respect to other projects going on in the community and how the flavor of the project fits into the big picture). That's why I split things like that.
R-OSGi perfectly fits into the environment of ECF and the efforts of the Eclipse community around distributed OSGi services seemed most mature to me.
On the other hand, jSLP is a protocol implementation and Apache has a long tradition in this field. Putting jSLP into the context of Apache Directory Server helps the project in several way, one is that there will eventually be a full Java SLP DA implementation, another is that there might be more interest in extending the implementation with things like IPv6 support and other issues that remained open so far.
All in all, I have always been at the point that the large open-source projects have enough in common so that they should be able to cooperate, despite obvious differences in their culture and structure. I hope you understand my point.

Cheers,

Jan.

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev