Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] ECF Luna planning 
Oops...I forgot the whiteboard example here it is:

(in provider activator.start...or ds)

// Register JSLPNamespace via whiteboard
context.registerService(Namespace.class, new JSLPNamespace(), null);
// Register JSLP container type description
context.registerService(ContainerTypeDescription.class,
new ContainerTypeDescription("ecf.discovery.jslp", new ContainerInstantiator(), 
        "JSLP Discovery Container", true, false), null);

On 3/31/2014 11:15 AM, Scott Lewis wrote:

Hi Folks,
I wanted to let everyone know that I've completed and resolved item 7 below (bug 421569 remove dependency on extension registry).
Although just one bug, this represents a pretty big change. As described in the comments on the bug, it allows both existing and new providers (e.g. distribution providers and/or discovery provider) to create new namespaces, container factories, and equinox adapter factories by multiple methods:
1) Declaratively (using equinox extension registry). This is how it has been. In other words, if the extension registry is present at runtime all providers will continue to behave exactly the same. 2) Programmatically (using the OSGi whiteboard pattern). This mechanism is new. Below is a very simple example of how to register a new Namespace and ContainerTypeDescription below. 3) Both 1 and 2. Provider implementer (us and others) can use *both* 1 and 2...and instrument things to make the choice at runtime.
This provides a nice degree of flexibility for consumers of ECF OSGi remote services in particular...whether for 'servers' or 'clients'...on equinox or on Felix/Karaf/others. For the existing providers listed on the bug comment (e.g. r-osgi, ecf generic, rest, zookeeper, etc), they will continue to work properly...whether the extension registry is present or not. As well, authors of new providers (us and others) can use whichever mechanisms that they choose (declarative, programmatic, or both).
IMHO by itself this justifies ECF 3.8.1...and I would like to contemplate/discuss the possibility of having a 3.8.1 maintenance release (we could do this fairly easily...e.g. this week). Or...we could wait for Luna, and get more of the items listed below completed and included into Luna. I'm currently torn. Comments/thoughts? 

Scott

 On 3/27/2014 11:20 AM, Scott Lewis wrote:

Hi Folks,
Here's what I'm planning for ECF for our Luna release (i.e. after ECF 3.8.0). This is partially to let everyone know what's going on/planned, and partially to solicit help/assistance from committers and/or contributors (i.e. you don't have to be a committer to get directly involved with these efforts).
The changes/updates/etc are somewhat 'invisible' so I wanted to make them more visible. There's actually a lot happening.
If you would like to get involved with any of these efforts please do so...by adding yourself to the associated bug, sending a note in response to this posting, and/or contacting me directly at slewis at composent.com. Everyone should be aware though that since we are a mature EF project, the deadline for getting the new things below into ECF Luna is ~end of April (i.e. before Luna release freezes).
1) Updating our implementation of OSGi Remote Services/Remote Service Admin for OSGi R6. For ~ 3 months now, I have been consistently updating our RS/RSA implementation based upon the OSGI RFC 203, on the git branch given in the bug [1] (and depends on). For your information, it's quite likely that nearly all of what's currently in RFC 203 will likely be in the R6 specification. R6 is not at all finalized yet, however, so all of our work is proceeding on an ECF branch [1a], which will be merged in to master when R6 specification is complete and approved. The timing and final content of the approval is not clearly known, however, so I'm not sure whether we will be able to do this merge before Luna release or not (my guess right now is that it will have to be a post-Luna maintenance release rather than merged/released in time for Luna). I'm the committer lead for this work.
2) Changes to ECF Discovery [2] and [2a]. [2] is work to make the RS/RSA usage of ECF discovery providers fully dynamic. Markus K has been working on this and is part-way finished (is my understanding). It will need to be coordinated with the work from 1...since the RSA 1.1 changes imply some additions/changes to discovery (addition of endpoint description update). Markus K is the committer lead for this work. [2a] is about updating the zookeeper provider to use a more recent version of Apache Zookeeper. Wim is the ECF committer lead for this work.
3) New distribution providers [3] and [3a]. [3] is websockets, and [3a] is for vert.x. Both of these would/will be great examples of using ECF's provider architecture to allow the easy creation of custom RS/RSA distribution providers. It would also be great if we can/could use these technical efforts to develop more tutorials for building and using custom providers (like our MQTT provider)...in addition to the [3b] tutorial. I am the lead committer for this work, although I would welcome others willing to take the lead on these additions.
4) RS/RSA integration with Python [4] [4a]. [4] is work that Thomas Calmant has largely already done, and [4a] is work with Thomas as well as the OpenReplica team to integrate Python-based remote service consumers and hosts via ECF Remote Services.
5) Use of Java8 for asynchronous remote services. As many of you know, java8 has some new features that are very interesting/useful from a remote services perspective...see [5] for example. I intend to get this work into Luna...as well as a new wiki-based tutorial demonstrating via our example async time service code described in the blog...which is now checked in, BTW [5a]). This is really exciting, IMHO, because it's right at the intersection between remote services...which have a strong need for asynchronous/non-blocking semantics...the java8 async/concurrency/functional programming features...and ECF's ability to easily and efficiently support async proxies...through our provider architecture, underlying event-driven structure, and existing support for async proxies [5b].
6) Possible GSOC 2014 projects. One request: Sakith...who I believe submitted a proposal for GSOC 2014 for an ECF project...please do two things: 
a) provide the URL/link of your proposal here on this list
b) please contact me via email at slewis at composent.com about mentoring
7) Make the use of Equinox extension registry optional [7]. In some runtime situations it would be helpful to not require the presence of the equinox extension registry. Work on making this happen has been underway on a separate git branch for some time now...see [7]...and it will make it into ECF Luna.
8) More RS/RSA documentation additions. As mentioned above, it would be great to get new tutorials for creating distribution providers, using java8/completable future for async proxies, use of ECF with Karaf, etc. There's now a lot more at [8], but there's much more to be done. 

9) Address as many existing bugs as possible [9].

10) Do all the required Luna releng/IP/EF stuff.
Thanks. If any questions, comments, suggestions...and/or things that I missed above that are going on...please let all know. 

Scott

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=424304
[1a] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git?h=rfc1.1

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=424059
[2a] https://bugs.eclipse.org/bugs/show_bug.cgi?id=378350

[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=426186
[3a] https://bugs.eclipse.org/bugs/show_bug.cgi?id=430221
[3b] https://wiki.eclipse.org/Tutorial:_Creating_a_RESTful_Remote_Service_Provider 

[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=424262
[4a] https://bugs.eclipse.org/bugs/show_bug.cgi?id=425817 http://openreplica.org
[5] http://eclipseecf.blogspot.com/2014/03/completablefuture-for-osgi-remote.html [5a] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/providers/bundles/org.eclipse.ecf.provider.remoteservice.java8 http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/examples/bundles/com.mycorp.examples.timeservice.consumer.ds.async 
[5b] https://wiki.eclipse.org/ECF/Asynchronous_Remote_Services

[7] https://bugs.eclipse.org/bugs/show_bug.cgi?id=421569

[8] https://wiki.eclipse.org/ECF#OSGi_Remote_Services
[9] https://bugs.eclipse.org/bugs/buglist.cgi?bug_severity=major&bug_severity=normal&bug_severity=minor&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=RT&list_id=8699254&product=ECF&query_format=advanced 

_______________________________________________
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

Back to the top