Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] Some Directions for ECF

Hi Folks,

It's been a while since there has been any public discussion about future directions for ECF, so I wanted to begin such a discussion. This note is not intended to be 'the story' for future work on the project lead...but rather I would like to start a discussion of some of the things that I think are useful for ECF well as my own uses of ECF (I'm a consumer too!). Rather, this is the start of a discussion...I would certainly like to hear from others about what they want us (committers and contributors) to take on. Please consider writing response to this posting...about your own thoughts.

So with that, here' goes:

Some Possible Future Directions for ECF

1) OSGi remote services. ECF already has a big technical investment in OSGi remote services...i.e. we have an RS implementation, but beyond that, we also have an implementation of the Remote Service Admin (RSA) spec as well...see [a]. Soon I expect that we will be able to claim full conformance to the OSGI Test Compatibility Kit (we have to get it from OSGI via Eclipse Foundation), and this will be good for the visibility of our implementation. Also, we are the only impl that has a provider architecture, making it much easier for OSGI remote services users to deeply customize and configure both remote services discovery and distribution. For example, it's currently possible for ECF consumers to 'mix and match' discovery mechanisms/protocols (file-based discovery, zookeeper, zeroconf, dnssd, slp, custom) with distribution providers (e.g. rosgi, ecf generic, jms, jgroups, restlet, custom). This is a huge advantage for OSGi remote services consumers, because it allows them to substitute the provider...and/or create their meet their specific needs WRT (e.g.) security constraints, performance, interoperability, etc.

But although this makes a great start, the work is not at all done here. More providers are needed...and some of the existing ones need to be updated (e.g. jgroups)...there's much more need for tutorials, examples, and documentation about how to create new providers and fit them into the OSGi remote services. We also badly need to get the work we've already done on remote service test frameworks into full operation and availability to consumers (e.g. adding the test framework to our own automated tests). Also...I would like to see some efforts around tooling for remote order to make it easier for folks to define, use, and maintain remote services. For example, at one point I started work on defining/using annotations to define remote services (e.g. @RemoteService).

Also, ECF has support for asynchronous/nonblocking remote services [b] already built in...along with a distributed eventadmin implementation.

To me, there's a very long list of things that can/could be done on OSGi remote services...and this is a great time to do OSGi remote services/RSA is (I think) really beginning to see some traction...on the 'server' side of IMHO it really is a great approach to doing SOA.

2) ECF on/with/for OSGi servers. OSGi is having more and more success on the web-server these days (just try to find a commercial app server that *doesn't* use it). ECF/OSGi remote services is a great fit here, IMHO. There is a lot to do, however, to make ECF more easily consumable/usable on OSGi servers, however...e.g. install/config/update...along with testing and tooling in server environment (as per 1)....and of course, tutorials, examples, documentation.

3) Mobile Clients. Clearly mobile clients need to communicate...with services, with other clients, etc. ECF has relevant components here...with OSGi or without OSGi. For example, I have created Android apps that use ECF generic code to talk with OSGi-enabled tomcat web server (running servletbridge, equinox, and ECF remote services). There is a lot of opportunity, I believe, to use ECF and OSGi remote services to create a very simple environment for creating both the service and the native mobile client....e.g. by having the service 'in the cloud'...using OSGi framework + ECF remote services...*and* having an API/library on the (say Android) client to make it easy for the Android app developer to communicate with/use/test those cloud services.

4) Collaboration for Tooling (and other apps). ECF has a lot of great work invested in collaboration support for developers...e.g. integration with IM, real-time shared editing/cola, irc client, tweethub, salvo, sharecode, google wave integration, bot framework, etc. There is a lot that could take this forward...e.g. work to integrate with Google Drive (which uses operational transformation...aka google wave), new Eclipse UIs (taking advantage of Eclipse 4) for dev communications/collaboration, etc. Also...we have access to VNC client code (written for another Eclipse project, since abandoned)...and there is a lot of opportunity to use Google APIs for collaboration, info sharing, in other ways within Eclipse and/or other RCP apps.

5) More/better support for SIP/VOIP/Skype, etc. We've got a lot of great work already done here, but it needs to be finished, reviewed, examples/apps written and deployed.

6) Documentation, tutorials, examples...ECF book...'nuff said. [c]

7) Bug fixes/backlog...'nuff said.  [d].  Enhancements [e]

Those are my thoughts about areas where I would like to see ECF progress over the next year. If there are others that you would like to convey, please write back...and/or open a bug or enhancement request so it doesn't get lost. If you are able, please consider contributing some work to ECF to make it happen...or even to mentor a GSOC student to that end as well. All contributions are welcome (bugs, code, docs, examples, use cases, etc).



[d] [e]

Back to the top