In Using ECF for Lightweight Distributed Team Collaboration
Scott Lewis (BEA Systems), started by stating the goals of the Eclipse Communication Framework (ECF) project: to “lower barriers to team and community communication by providing [an] interoperable, integrated, extensible framework”.

Scott spoke of team productivity. Specifically, he talked a book by Scott E. Page, “The Difference” that explains how “diversity trumps ability”. The gist of the discussion is that a distributed group of motivated people with varying skills and ability can outperform a group of people who are (merely) highly skilled (yet not diverse in background, skills, and ability). Productivity was presented as motivation for the team collaboration tools provided by ECF.

Scott showed off how ECF can be used to hook into IRC channels using a view inside Eclipse. The then showed how more private communication between developers is possible. Using workspace collaboration, developers can open shared editors and work together on the same file in a totally distributed fashion. Scott also demonstrated sending screen shot, communication via IM and Skype (there’s an implementation of VOIP that uses Jingle under development) and file transfers. Scott says that there’s also some Mylyn integration which allows task contexts to be shared via IM. Many different forms of communication are supported. I believe that Scott was using XMPP for the demonstration, but GoogleTalk and other protocols are also supported.

Markus Kuppe stepped into show off the discovery APIs; these APIs enable ECF to find services. Scott then showed off the Service Discovery view (shown to the right) which showed the services exposed by all the systems connected to the EclipseCon wireless network (which, frankly, was a lot). I liked it when Scott found a box sporting an Eclipse update site, and—with a single right-click of the mouse on that update site—he opened the Update Manager and added the update site to the list. It’s no surprise that some of this technology will find its way into the new “p2” provisioning solution being built by the Equinox project.

For kicks, I’ve shown what the Service Discovery view found around me (using the version of ECF found on the Ganymede update site). There sure are a lot of iPhones connected to the EclipseCon network…

Update: with apologies to Markus Kuppe, I have corrected the previous misspelling of his name.

This morning, after the throught-provoking keynote by Cory Doctorow, I sat in on the Eclipse Riena Project session, presented by Christian Campo (compeople AG, Frankfurt/Main, Germany)

Fundamentally, Riena is about distributing services across tiers. It’s born from a need to have applications that are lighter than rich clients, but more functional and performant than light clients. Applications built on Equinox (like those leveraging Eclipse Rich Client Platform, or OSGi-based server-side applications) are compositions of bundles and services. Equinox services are conceptually similar to web services; they are created, registered, discovered, invoked, deregistered, updated, etc.

One big difference between web services and Equinox services, is that Equinox services tend to be used locally (i.e. within a single JVM). Riena extends this to allow bundles and services to be distributed across tiers by providing a mechanism for creating proxies for OSGi services on the client. Proxies exchange messages and data to server. The true location of the service is transparent to the code that makes use of the services; you talk to the service like it’s local and it takes care of communicating with the real service wherever it lives. Riena includes infrastructure that automatically creates a proxy and connects it to the running service on a remote machine. I assume that it uses the Proxy class in Java to automatically create an instance of the specified interface that knows how to talk to the remote service.

Riena provides some other handy services, like authentication and authorization. The current implementation uses JAAS security for now., but they intend to migrate to Equinox security (which is currently part of the Equinox Incubator) in the future. Authentication is provided via a service that runs on the server, and is exposed to the client (via proxy). Once established, credentials flow from the client to the server automagically as part of the communication. Some infrastructure is provided to manage authorization.

Riena has a “Visual Vision”. Christian showed a user interface that they created for a client. The user interface, coded using Swing (the work began several years ago before they were fully introduced to the wonders of Eclipse Rich Client Platform), shows some interesting user interface concepts. Christian made a good point that, while the flexibility in the “Eclipsey” user interface makes sense to us, end users are often thrown off by it (e.g. how do you get a view back when you close it?). Development of the user interface concepts hasn’t been started in earnest yet, but is on their plan.

People often ask us why we have EclipseCon in Santa Clara every year.

This is the convention center in Santa Clara:

(note the fountains on the left, the palm trees, and the generally warm glow).

This is my home in Ottawa (where most Eclipse Foundation employees live):

(note the after effects of more than 4m of snow).

Does that answer the question?

Sometimes it feels like I’m stalking Frank Gerhardt. Or maybe I just like listening to German speakers. Whatever the case, it seems that almost every single talk I’ve attended has been presented by Frank, or one of his countrypersons…

This afternoon, I’m attending “Server-Side Eclipse - the dynamic server platform based on OSGi” presented by Jochen Hiller (Deutsche Telekom AG, Germany), Frank Gerhardt (Gerhardt Informatics).

“Server-side Eclipse” is a term that shocks some people. What does it mean for Eclipse to run on a server? If perception is reality, then perception tells us that “Server-side Eclipse” means “Eclipse IDE for Java Developers running on the server”. What we really mean is “Equinox running on the server”. Equinox is the component model, based on the OSGi specification, that underlies Eclipse. An Eclipse product (like Eclipse IDE for Java Developers) is a collection of plug-ins (or bundles) and Equinox is what makes sense of it all and makes it work. Equinox can help you make a server-side application based on bundles; Equinox makes sense of it all.

One of the big deals in Equinox is services. Bundles can register services with the service registry. The notion of a service is very similar to that of a web service, but with much less weight. Services are registered and unregistered, they can be discovered, and behaviour invoked. One of the tricky things about services is that they can easily come and go. By their nature, bundles are very dynamic and can be started, stopped, unloaded, updated, etc. at any time. As bundles come and go, so do their services. ServiceTrackers help us keep track of the comings and goings of services; we can use a ServiceTracker to get a handle on a service, but we need to be careful not to depend on that handle being valid forever. As a general rule, you get the service, use it, and then unget it. The next time you obtain the service, it might be an entirely different implementation. Or it might not even be there. You need to be ready for that.

The demo they’re running is similar to a tutorial/demo that I built a couple of weeks ago. Their demo differs in that they’re showing a lot more of the general coolness of dynamically installing, starting, and stopping bundles. Their demo also takes it one step further than mine by showing an Über-cool RESTful web service (an Equinox service implementation of a RESTful web service).

In what I am certain is an attempt to make my demonstration seem pitiful and weak, they’ve shown how a new version of a bundle can be installed and started alongside the old version, which is then stopped. All this, while a client is constantly pinging the server and showing us how the output changes as the new bundle is brought online. The gauntlet has been thrown, my next screen cam is going to show all this. And more…

My big takeaway for this session is “Today is good choking”.

I’ve tinkered with the JFace DataBinding, but haven’t had a chance to really dig into it. So, this afternoon I attended “Understanding JFace Data Binding“, presented by Boris Bokowski (IBM Rational Software), Michael Scharf (Wind River), and Frank Gerhardt (Gerhardt Informatics). I loved the presentation style. They very likely didn’t plan for the rough edges around the presentation, but I found it effective. Boris would say things like “of course, you have to have an ObservablesManager” and Michael (who was driving the demo), would say, “what?!?”. Then they’d update the implementation and tell us about it. A very effective way of making sure that folks in the audience would remember (or maybe they did plan it).

One thing is clear: using the DataBinding framework significantly reduces the complexity of building user interfaces. That said, it’s also clear that specifying bindings can get a little weird. It’s definitely ripe for generation by a GUI designer (Instantiation’s WIndowBuilder will generate the binding code). It’s a heck of a lot easier to understand the steps you need to take if you’ve done it the hard way first. Initially, it occurred to me that—if I were to deliver this session—I’d show the hard way first. After some sober reflection, however, I figure that showing somebody the “hard way” is virtually guaranteed to melt at least a few brains. Bottom line: some parts of the DataBinding may seem weird or hard, but it’s way easier than the old-fashioned way.

One thing that I really like about the framework is the level of control that you’re given over validation, conversion, and updating. You can, for example, defer the actual updating (e.g. moving the value typed in a text field into the model object) until the user clicks “Okay”, “Finish”, or whatever. There are also several opportunities to validate the information (before conversion, after conversion, before update).

There are examples that show you how to use DataBinding in Eclipse CVS; look for org.eclipse.jface.examples.databinding. The Examples project is going to make use of this.

I sat in on Marcel Offermans’, Karl Pauls’ (both from luminis) tutorial titled “Building Secure OSGi Applications“. Marcel and Karl provided a good incremental discovery approach to the tutorial, starting with the pre-OSGi 4.0 way of managing permission and moving quickly into the state of the art. The take-away from this tutorial for me is that—if you need security in your OSGi application—ConditionalPermissions and BundleSignerConditions are the starting point.

The basic idea is that you can specify a permission that says, “only grant permissions X, Y, and Z to any bundle that’s signed by so-and-so”. You can say, for example, that only your bundles (i.e. the ones signed by you) can write to the file system, or control who can import certain packages (I haven’t tried this last one, so I’m guessing that a relatively fine level of granularity is supported). There’s other kinds of conditions, including BundleLocationCondition which lets you grant permissions (curiously enough) based on the location in the file system of the bundle. You can use this condition to match a bundle’s symbolic name, assuming that the standard of using the symbolic name as the bundle JAR’s name is followed. My intuition is that this isn’t as useful as conditions based on signers, but this may change as I spend more time looking at it.

At this point, it seems that permissions can only be specified programmatically. It seems to me that creating a bundle that lets you specify permissions declaratively shouldn’t be too much work. Marcel stated that he’s not aware of any open source projects currently looking at this.

The tutorial worked mostly from the command line (using Ant to build) which I found a little disturbing. Naturally, I got caught up in making it all work using the PDE and a launch configuration within Eclipse so that I could (easily) use the debugger (Marcel suggested that I just attach the debugger to the application invoked from the command-line). It was actually pretty easy to get this running using the PDE, but did require some reconfiguration of the provided example projects.

I’ll have to incorporate this into an example.

Jesper was curious about Subclipse use captured by the Usage Data Collector, so I tweaked my queries to stop obfuscating the Subclipse bundles. The results for Subclipse and Subversive use by 465 users over the past 14 days are shown here.

First, the commands:

• org.tigris.subversion.subclipse.ui.commit (invoked 805 times)
• org.tigris.subversion.subclipse.ui.update (invoked 556 times)

It doesn’t appear that the Subversive plug-ins make use of the command framework (or I’m looking for the wrong name).

Perspectives:

• org.tigris.subversion.subclipse.ui.svnPerspective (activated 160 times)
• org.eclipse.team.svn.ui.repository.RepositoryPerspective (activated 128 times)

Views:

• org.tigris.subversion.subclipse.ui.repository.RepositoriesView (opened 119 times by 32 users)
• org.eclipse.team.svn.ui.repository.RepositoriesView (opened 178 by 22 users)
• org.eclipse.team.svn.ui.repository.browser.RepositoryBrowser (opened 20 times by 9 users)
• org.eclipse.team.svn.ui.properties.PropertiesView (opened 20 times by 12 users)

For comparison, the CVS Repositories view was opened 189 times by 57 users.

It looks pretty close to me; at this point, I don’t think we have enough data to make any real conclusions…

Over the past 14 days, 453 (526 in total) of you have consented to upload your usage data to the Eclipse Foundation server. There hasn’t been a lot of change in the top five commands:

• org.eclipse.ui.file.save 87098
• org.eclipse.ui.edit.text.goto.wordNext 71274
• org.eclipse.ui.edit.delete 66449
• org.eclipse.ui.edit.paste 57309
• org.eclipse.ui.edit.text.goto.wordPrevious 51138

Perspective use has some interesting parts, though they occur a little further down the list. It seems that most of us are using Eclipse for Java development:

• org.eclipse.jdt.ui.JavaPerspective 4592
• org.eclipse.debug.ui.DebugPerspective 2240
• org.eclipse.team.ui.TeamSynchronizingPerspective 1155
• org.eclipse.jst.j2ee.J2EEPerspective 1095
• org.eclipse.jdt.ui.JavaBrowsingPerspective 111

I find it curious that so many among us use the Java Browsing Perspective. It must be all the Smalltalkers in the crowd…

A few fewer of us are using the PDE:

• org.eclipse.pde.ui.PDEPerspective 299

Use of the CDT and PDT appears to be quite healthy:

• org.eclipse.cdt.ui.CPerspective 182
• org.eclipse.php.perspective 87

Subversive seems popular:

• org.eclipse.team.svn.ui.repository.RepositoryPerspective 122

You can view all the results on the EPP Usage Data Collector results page.

I’ll be arriving at EclipseCon on Sunday and will be there all week. While I’m there, I’d like to talk to you. Yes you. And you. You also.

To make it as easy as possible, here are some topics we can discuss:

• The Eclipse Examples Project (which successfully passed its creation review today)
• The Eclipse Summer of Code project and Google Summer of Code
• Equinox, OSGi, bundles, and services
• The timing (good or bad) of your BoF submission
• Changes to the Eclipse Development Process
• What’s up with the Technology PMC
• My curious (though completely non-weird nor threatening) obsession with Megan Follows
• Whether or not I’m going to attempt to eat that pizza
• Polar bear dips (no, I didn’t do it this year)
• Weather in Ottawa
• The Senators
• Minor hockey (specifically novice and peewee levels)
• Karate

If I missed anything, we can talk about that too…

The Usage Data Collector (UDC) is now part of the milestone 5 builds of the Ganymede packages produced by the Eclipse Packaging Project (EPP).

It seems that about 10% of those who have downloaded Ganymede M5 packages are participating in our usage data gathering exercise (1.2 million usage data events have been captured on our server over the last 14 days). If anybody is keeping score, the top 5 commands over the past 14 days are:

• org.eclipse.ui.file.save 35925
• org.eclipse.ui.edit.delete 31631
• org.eclipse.ui.edit.text.goto.wordNext 25868
• org.eclipse.ui.edit.paste 23218
• org.eclipse.ui.edit.text.goto.wordPrevious 18377

More results are available on the UDC results page.