ECF 2.0.0 New Features video

It can't match Ed's pictures, but below is a pleasant scene, where most of the beauty is hidden beneath what is visible



But to the point: ECF has a new video showing some of the new things in ECF 2.0:

• Screen shot sharing
• URL sharing
• Real-Time shared editing
• Discovery API, Service Discovery, Remote OSGI Services
• Async File Download

Enjoy

Freed from email

There's an interesting article about use/abuse of email in the NY Times today:

I Freed Myself From E-Mail’s Grip

FWIW, I think ECF is doing it's part on this problem, by providing multiple ways for Eclipse users to easily, cheaply, and openly communicate and collaborate.

Also, for those interested, there is a longstanding proposal to add an XMPP server at Eclipse Foundation in order to help teams build and maintain community.

ECF 2.0.0

With Ganymede the ECF project has it's 2.0.0 release. As for what's new....there were many little things, as well as many big but invisible things (i.e. APIs), but the things that really stand out for me are

• Real-time shared editing (with a quickly-becoming popular video)
• Discovery API: Simplified API and added jSLP provider
• Remote OSGi Services API: Added provider based upon r-OSGi
• P2: ECF's asynchronous file transfer API is used for P2's multi-protocol download, and so is part of the SDK.
• Community Growth: We added some great new committers to the project: Markus, Jan, Ted, Mustafa, Marcelo...as well as many more contributors.
• New and Noteworthy for details and more

This is ECF's last release as a technology project...as we will soon be moving to the new Runtime top-level project for 2.1 and beyond.

I like to say: 'the community is the team' :)...so congratulations and thanks to the ECF community.

P.S. You can find/install ECF's features in the Ganymede Communications category.

Adding Shared Editing To Your Favorite Text Editor

With ECF 2.0/Ganymede, ECF introduces Real-Time Shared Editing. By default, the ECF real-time shared editing capability has been added to the JDT Java Source Code editor and Eclipse's Default Text Editor.

I've begun documenting how those with other types of Eclipse-based text editors (e.g. C/C++, php, javascript, xml editors, etc) can add real-time shared editing to their editors...simply by adding a little bit of markup to plugin.xml. See here for explanation and example.

Articles on ECF

There are now a couple of articles on Eclipse Communication Framework for version 2.0.0/Ganymede release:

InfoQ: http://www.infoq.com/news/2008/06/eclipse-ganymede-ecf
DZone Interview: http://java.dzone.com/news/the-ecf-project-an-interview-w

Eclipse and Volunteerism

In response to a recent news thread, Bjorn Freeman-Benson says

As Dan Ariely explains in "Predictably Irrational", there is a huge difference between real volunteer and paid volunteer (Eclipse is 'paid volunteer').

I want to examine briefly Bjorn's assertion that Eclipse is 'paid volunteer'.

In looking at the Dash commit count sorted by # of commits, the thing that jumps out at me is that for 2008 individuals, are right after IBM in terms of # of active committers (23.56%), commits (159,279), and lines of code (4,982,101).

There are/should be many qualifiers for these data: I'm sure many of the independents are paid to work on Eclipse...but conversely it's quite possible (and likely, I think) that some corporate-supported committers work more on Eclipse-related work...by their own choice...than their employers explicitly sanction. But in any event, I think the overwhelming message from the data is that the contribution from independents (many of whom are unpaid volunteers I would suppose) is large...and growing rapidly year-over-year.

All I'm saying is that 'Eclipse' is not necessarily 'paid volunteer'. But it does have a strong aspect of unpaid volunteerism, which as Bjorn (and Eric Rizzo) point out, should be encouraged and supported:

The place that Eclipse overall has not done a good job is making our projects attractive to unpaid, part-time volunteers. They're different. Their motivations are different. The Rizzo Ceiling is real for them.

For some pointers to interesting thoughts about motivations, please see

When Self Interest Isn't Everything

Seems that while I was typing this out, Boris Bokowski has also made some similar points.

projectDiversity.equals(productivity)

I have started reading the book described in this article

In Professor's Model, Diversity = Productivity

After reading some of his book, it seems that cognitive diversity (defined as group differences in perspective, heuristics, interpretation, and prediction) generally lead to improvement in overall productivity. There are other kinds of group differences, of course...e.g. what Page calls identity differences (e.g. racial, gender, and social group), and other sorts of differences, but Page identifies cognitive differences as key.

Increased productivity is dependent upon the problem/task at hand, of course. Group tasks/problems that hinge on questions of representation and interpretation get greater value from diverse perspectives, since such diversity allows more alternatives to be generated and considered.

My thought on reading this was that many sw design tasks are like this (i.e. hinge upon how the problem is represented) and so should be particularly good candidates to benefit from teams with high cognitive diversity...and the many perspectives that come with such groups.

Interestingly, Page also identifies a type of diversity that seems to result in lower group productivity...I'll talk about that after I've read a little more.

When Self-Interest Isn't Everything

An interesting editorial by an economist in today's NY Times

When Self-Interest Isn't Everything

Is Hirschman's analysis (described in editorial) relevant for the open source 'movement'? How much of open source is/will be about self-interest?

Discovery and Access for Remote OSGi Services

See here for some work combining the ECF discovery API with the ECF remote services API.

Interesting things about this:

1. ECF APIs have multiple providers...i.e. zeroconf/bonjour and SLP for discovery, r-OSGi, ECF generic, xmpp, javagroups, and multiple flavors of JMS for remote services. This allows middleware and UI written to these ECF APIs to run unmodified on any/all of these providers.
   
2. The ECF remote services API can be used in either 'transparent' or 'non-transparent' manner...allowing programmers to decide whether network transparency for remote procedure call (RPC) is appropriate for their application...or not.

In time for EclipseCon, I intend to expose some of the Equinox p2 APIs as remote services, so that OSGi containers can be remotely provisioned and managed. If you would like to participate in this, please contact us and offer to contribute.

Project Diversity = Productivity?

In today's New York Times is this intriguing interview:

In Professor's Model, Diversity = Productivity

Given the past year's frequent postings regarding project diversity (e.g Bjorn, Doug, Committer Reps, and many of the always-beautiful postings by Ed Merks), this research seems relevant.

I haven't had a chance to read the original research yet, but this caught my eye in the interview:

What the model showed was that diverse groups of problem solvers outperformed the groups of the best individuals at solving problems. The reason: the diverse groups got stuck less often than the smart individuals, who tended to think similarly.

The other thing we did was to show in mathematical terms how when making predictions, a group’s errors depend in equal parts on the ability of its members to predict and their diversity. This second theorem can be expressed as an equation: collective accuracy = average accuracy + diversity.

Real-Time Shared Editing over XMPP

The ECF project has been adding some real-time collaboration functions for dev team support...for example, sharing selected text in Eclipse editors, as well as real-time collaborative editing...all over the ECF datashare API...which means you can use your favorite public IM accounts like google talk, or skype rather than be forced to have yet another account. We've also got some new sharing of Mylyn tasks as per bug 195737.

ECF 1.2

ECF 1.2 has just been released. Highlights: lots of UI work (not all of it with zx's picture...is that a UI improvement? ;-), cool work on remote services, discovery API improvments, and a fair amount more. Lots of great community contributions via BugDay.

Remote OSGi Services: Questions of Transparency

Recently, I've been having discussions with various folks about whether network transparency for remote OSGi services is a 'good thing'.

I think a reasonable summary of the discussion is that under the right conditions, it can be a good thing, because it makes it possible to easily create distributed applications using consistent APIs...without learning network specific service APIs.

OTOH, under the wrong conditions and assumptions, too much network transparency can make it very hard or impossible to build reliable distributed components or applications (for details see the classic Note on Distributed Computing Paper).

With our own Remote Services API in ECF, we've tried to create an API so that it's easy to use either approach...and attempt to steer clear of the religious wars. So, for example, in ECF here's how you register a remote service (for the 'server' of that service) to be accessed ...either transparently or not-transparently:

IConcatService serviceImpl = new ServiceImpl();
Dictionary props = new Hashtable();
props.put(Constants.LOCAL_SERVICE_REGISTRATION, "true");
// Register serviceImpl
context.registerRemoteService(new String[] {IConcatService.class.getName()}, serviceImpl, props);

And then on the service client, you can access it like any other OSGi service...and underneath a proxy is created (this looks exactly the same whether the service is local or remote):

ServiceReference ref = bc.getServiceReference(IConcatService.class.getName());
IConcatService concatService = (IConcatService) bc.getService(ref);
concatService.call();
// call concatService...calls proxy and sends the call to remote serviceImpl

Alternatively, clients can also access a IRemoteService instance via a service property, and do things like send an asynchronous message to invoke the service...for example:

ServiceReference ref = bc.getServiceReference(IConcatService.class.getName());
IRemoteService remoteService = (IRemoteService) ref.getProperty(Constants.REMOTE_SERVICE);
// Call it with listener for return/result. This returns immediately and then later
// calls the remoteCallListener
remoteService.callAsynch(remoteCall, remoteCallListener);

Of course you could claim that is chickening out on the transparency battles, but I tend to think of it as simply recognizing that there are lots of distributed applications out there that can (and should and will) be implemented on OSGi runtimes, and they all differ in their needs...e.g. for synch vs. asynch, or handling of partial failure, or in their timing/performance requirements.

Messaging for Servers

Among some of the New and Noteworthy for ECF 1.1 are some new providers

ActiveMQ/Websphere CE (JMS)
BEA Weblogic (JMS)
JGroups

The first two depend upon/use commercial implementations of the Java Messaging Service (JMS) associated with Websphere Community Edition and BEA Weblogic, respectively. ActiveMQ is also an Apache open source project (activemq.apache.org). The third is an open source reliable multicast implementation used in JBoss called JavaGroups.

Included with each of these providers is an Eclipse IApplication that allows them to be run as a stand-alone OSGi/ECF-based server.

This also expands the set of providers that support the ECF remote services API: an API for invoking OSGi services remotely...via synchronous method call and/or asynchronous invocation. Each of these providers implements the ECF remote services API, showing that a single API for remoting really can (and does) run on multiple wire transports and multiple network topologies...an elusive goal for much of the web services world.

Remote OSGI over XMPP

In a previous post, I showed how real-time collaboration could be added to Eclipse/RCP apps using ECF datashare API running on the ECF XMPP provider.

One can also use ECF to make remote OSGi calls using the ECF remoteservices API.

For example, on an ECF XMPP peer that is to be the 'server' for a given service (a trivial IConcatService in this case):

  // Get ECF adapter for remote services
  IRemoteServiceContainerAdapter adapter =  ... (e.g. from contacts list)
  // Get targetID[] buddies who are to receive service registration
  ID [] targetIDs = ... (e.g. from contacts list)
  Dictionary props = new Hashtable();
  props.put(Constants.SERVICE_REGISTRATION_TARGETS,targetIDs);
  // Create service instance...this does the actual concatenate
  Object concatService = new IConcatService() {
          public String concat(String string1, String string2) {
              return string1.concat(string2);
          }
      };
  // Register service instance
  adapter.registerRemoteService(new String[] { "IConcatService" }, concatService, props);
  // Service now registered

And for clients to lookup and use the service:

   // Get adapter for accessing remote services
  IRemoteServiceContainerAdapter adapter =  ...
  // Get remote service reference
  IRemoteServiceReference[] refs = adapter.getRemoteServiceReferences(null, "IConcatService", null);
  // Get service for remote reference
  IRemoteService service = adapter.getRemoteService(refs[0]);
  // Create remote call
  IRemoteCall remoteCall =  new IRemoteCall() {
          public String getMethod() {
              return "concat";
          }
          public Object[] getParameters() {
              return new Object[] { "Eclipse", " is cool" };
          }

          public long getTimeout() {
              return 3000;
          }};
  // Call synchronously
  String result = (String) service.callSynch(remoteCall);
  System.out.println("concat result is: "+result);
  // prints out:  concat result is: Eclipse is cool

Further, note that the client can use any of the 'style's of remote invocation desired:

IRemoteService.callSynch(...)
IRemoteService.callAsynch(...)
IRemoteService.fireAsynch(...)
IRemoteService.getProxy()

With 'getProxy()' this returns an instance that implements IConcatService, and allows direct method invocation:

IConcatService concat = (IConcatService) remoteService.getProxy();
String result = concat.concat("OSGi"," is cool");
System.out.println("concat result is: "+result);
// prints out:  concat result is: OSGi is cool

There is more test and example code available here. Note that with the IRemoteService.callAsynch, callSynch, and fireAsynch methods it is not even necessary that the client have the service interface locally. All that is needed is the string identifying the desired class name.

The support for remote services on the ECF generic provider is already in ECF 1.0.0, and the support for doing remote services on XMPP will be available in ECF 1.0.2.

Real-time Collab Over plain 'ol XMPP

Something cool: real-time collaboration in Eclipse via XMPP. The point here is that with the ECF Datashare API, it's possible to send arbitrary messages to folks on your XMPP (or Google Talk, or soon Skype) buddy list, and with the new Eclipse 3.3 menuContribution API, it's very easy to create your own plugin, that uses ECF's MultiRosterView to add on your own actions (like making a Skype call, or sending an URL to team mate, or playing Sudoku with a buddy, etc). No need to understand XMPP, to use any of this, just send/receive data (byte []s).

Now available via dev/integration build. See here for links to latest download.

Here's a class which is responsible for sending/receiving the URL (most of it is UI code. See sendURL and handleMessage/showURL).

Skype Provider for ECF

ECF is soon going to make available a dev build for a Skype Provider. If you have some appropriate sounds, please consider donating them to us to use as a ring tone within Eclipse. See bug #182840.

ECF 1.0.0 milestone 6 released

ECF 1.0.0 milestone 6 released. Some cool new stuff...e.g.

1) A new 'bot' API/plugin (org.eclipse.ecf.presence.bot) to allow people to create IM and chat room robots that can respond to messages.
2) Committer Remy Suen has created a very cool Bot Framework Tutorial.
3) A history API for IM/chat room history.
4) Peer-to-peer file transfer over XMPP
5) Work on file transfer API to support the Equinox provisioning incubator effort.

Here's the download page: http://www.eclipse.org/ecf/downloads.php
New and Noteworthy: http://www.eclipse.org/ecf/NewAndNoteworthy.html

And we've done lots of work on making the ECF core and API plugins able to run on any/all Equinox runtimes (e.g. servers, RCP, Eclipse, etc). See this bug here for details: bug #176322.

Next Up: Implementation of ECF call API with Jingle (Google Talk), and Skype as well as support for Europa M7, further work on supporting Equinox provisioning as needed, a continuous build server for daily integration builds, and bug fixes (of course).

ECF 0.9.6 stable released

ECF is releasing 0.9.6 stable today (Jan 13, 2007). It has quite a few positive changes in the simplification of the presence API, the easier creation and customization of roster user interfaces via the new plugin: org.eclipse.ecf.presence.ui, use of the new connect and configuration wizard extension points, and lots of bug fixes. See here for the download, here for the New and Noteworthy, and here for the planned and completed fixes and enhancements.

ECF 0.9.4 Stable Released

ECF 0.9.4 stable released. Download here. New and Noteworthy here. Also created project milestone plan (tentative) and put here.