Project Plan For Eclipse Communication Framework, version 3.0

Introduction

Previously, ECF has had three major releases: ECF 1.0.0 as part of Europa Simultaneous Release, ECF 2.0.0 as part of Ganymede Simultaneous Release, and ECF 3.0.0 as part of Galileo Simultaneous Release. This plan describes the work for ECF 3.2, which will occur in June, 2010 as part of the Helios Simultaneous Release.

Release Deliverables

The major ECF 3.2 release deliverables are as follows:

  1. Extend ECF Discovery and Remote OSGi Services, and support the OSGi 4.2's Remote Services standardization
  2. Implement a Google Wave-compatible ECF provider
  3. Improve and Extend the ECF Example Applications, with special emphasis on ECF remote services and discovery examples
  4. Enable easier creation and use of Equinox+ECF-based Server Runtimes

Table of Contents

Release Milestones

ECF plans on delivering milestone on the same general schedule as the Helios Simultaneous Release schedule, starting with M4. ECF has both +0 and +1 components. The +0 components will be on same release schedule as the Platform, and the +1 components will be as specified below.
M412/18/2009
M52/5/2010
M63/19/2010
ECF 3.2 API Freeze
M75/7/2010
ECF 3.2 Feature Freeze
RC15/21/2010
RC25/28/2010
RC36/4/2010
RC46/11/2010
3.26/23/2010
Helios GA/ECF 3.2

Table of Contents

Target Environments

ECF's target environments are:
  • Eclipse
  • Eclipse-based Applications
  • Eclipse RCP
  • Other Equinox-Based Runtimes (e.g. Equinox servers and CDC1.1/Foundation 1.1 environments)

Internationalization

ECF doesn't perform internationalization directly, although we develop our plugins following common rules about string externalization to make the automation possible

Table of Contents

Compatibility with Previous Releases

ECF has a policy of maintaining API backward compatibility with minor and service releases. API is considered all exported packages (i.e. packages that do not have

x-internal:=true
in their Export-Package declaration. As an example, with the following declaration in the org.eclipse.ecf MANIFEST.MF

Export-Package: org.eclipse.ecf.core, org.eclipse.ecf.internal.core;x-internal:=true
       

The org.eclipse.ecf.core package is API, and the org.eclipse.ecf.internal.core package is not

Only with major releases (e.g. 2.0.0, 3.0.0) are incompatible API changes to be introduced (e.g. refactorings, renames), and even then only after discussion among multiple committers. For the parts of ECF used by the Platform (e.g. the core and file transfer bundles), NO incompatible API changes will be introduced, even for major releases, in order to maintain the platform backward compatibility constraints.

Table of Contents

Themes and Priorities

Remote Services

In our Galileo/ECF 3.0 release, ECF included support for the OSGi Enterprise Experts group's RFC119 (Distributed OSGI). This DRAFT specification provides consistent service property constants, as well as java classes for making services registered as local services available as remote services. The two major technical components of the RFC119 DRAFT spec were discovery (for allowing client to discoverying in some manner services exposed by other frameworks), and distribution (for actually accessing and calling the service). In ECF 3.0, ECF included full support for the DRAFT RFC119 specification, and implemented this support via the ECF discovery API, and the ECF remote services API (distribution). The use of these two APIs, independent of provider transport, uniquely allows multiple transports to be used without application-level code changes (e.g. using JMS, r-OSGi, and/or new providers without code changes).

In the summer of 2009, the OSGi standards organization chose to simplify and rename the RFC119 specification, as well as rename it 'Remote Services'. One simplification that was made in the Remote Services chapter of the OSGi 4.2 specification was to *only* define service constants that clients must/can use to register, publish, discover, and access remote services, while leaving out all java interfaces and classes from the specification itself. One of our efforts during the last few months of 2009 will be to rename our existing constants to support these new constants. This will then give our existing implementation full compliance with the new Remote Services specification.

  • Proposed
    • [remotesvcs][websvcs] Publish remote services through Web Services [290748] (target milestone: 3.2.0)

Google Wave

In spring of 2009, Google announced a new system called Google Wave. In ECF 2.0, ECF introduced a real-time shared editor called DocShare, and the underlying synchronization engine based upon operational transformation was generalized in ECF 3.0 to provide a generic synchronization API. This API is based upon our own operational transformation implementation refered to publicly as Cola.

ECF's existing provider architecture allows us to easily support new protocols (such as the Google Wave server protocol described at waveprotocol.org), our existing synchronization API (org.eclipse.ecf.sync), as well as our existing XMPP provider (based upon Smack XMPP implementation), allow us to relatively easily create modules that allow an Equinox+ECF-based web server to interoperate with a Google Wave server. We propose to implement such a Wave-protocol-compliant server, using Equinox+ECF+other EclipseRT technologies.

  • Proposed
    • [wave][provider] implement wave protocol as new ECF provider [280347] (target milestone: 3.2.0)

ECF Remote Services and REST-based Webservices

As part of his 2009 Google Summer of Code project, Holger Staudacher used and extended the ECF remote service API to allow REST-based (Representational State Transfer) APIs to easily be accessed as remote services. REST-style APIs are increasingly popular for web services, and ECF now has a REST API for accessing and using REST-based remote services, and treating them as with every other remote service (i.e. via the ECF remote service API).

ECF 3.1 (for Oct 7, 2009 release) will include this REST API, but during the ECF 3.2/Helios release cycle we will extend the existing API, and include additional API to support the easy creation and publication of REST-based web services.

  • Proposed
    • [remotesvcs][websvcs] Publish remote services through Web Services [290748] (target milestone: 3.2.0)

Table of Contents