[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] ECF Luna planning
|
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
