EclipseCon has been an energetic event, with early mornings and late nights (and quite often, a large amount of beer). This is starting to affect people and it feels like the conference has started to wind towards the close later today. Of course, there's no exhibitors today so that may have an affect on the number of attendees.

Last night, I attended a couple of birds of a feather discussions on BIRT and the Update Manager. The BIRT talk was interesting, finding out how people are using the BIRT engine; and it should be possible to use the BIRT charting engine to run inside an RCP application that has nothing to do with reports. Unfortunately, examples are somewhat lacking in this regard and hopefully new ones will be available in the future. What's interesting is that they also use the Rhino framework for executing JavaScript against the charts htemselves; though at present, it's a mandatory dependency rather than an optional one (meaning you've got to ship it, even if you don't use it). Hopefully examples or modification to the features will change this situation. Interestingly, they've got a competition to win one of two PSPs; one showing the most technical use of BIRT, and one showing the prettiest graphical results of a report.

The other BoF was an open discussion of the update manager. It provoked a lot of interesting comments; we didn't end up leaving until 23:15 (and it started at 21:30; one of the reasons why I am a bit behind this morning!) The original goal of the BoF -- an open source repository for bundles and changes to the update manager -- was extended to also deal with issues regarding deployment and management of Eclipse installations in an enterprise situation. There were some good ideas that came out, but given the time available we ended up really understanding the problems that people would like an update system to do rather than necessarily proposing ways of fixing them. The kind of issues raised involved:

• Can there be a delta distribution for bundles? Using Pack200 is good for compression, but can this be applied with older versions of the same bundle as well?
• How can many repositories co-exist at the same time? There may be desires to have a global federated set of plugin repositories, such as developer-level, project-level, department-level, corporate-level or even global-level. [I'm not sure whether this meant repositories for installation, or for mandates on Eclipse installations managed at those levels - Al]
• How internally-developed plugins can be distributed/deployed
• How applications can be co-hosted to maximise bundle re-use
• Multi-threading the download implementation
• Being able to resume downloads of incomplete plugins using restartable HTTP instead of starting download again
• User profiles for managing which plugins are allowed to be used (i.e. selective authorization of internal plugins)
• Management of preferences as well as plugins at a developer/project/departmental/corporate/global level

This caused a good debate about the current implementation of Update Manager, and how it doesn't address these needs above. Some out-of-the-box thinking led us in directions of:

• Using a protocol like RSync or similar to send diffs of updatable components (though a JarDiff tool would have better results). This presupposes that the previous version is available for comparison in order to generate the diff. Binary diffs of Jar-like structures may not be sufficient since the binary versions often change over the file even when the change is small and localised.
• Could the PDE suggest or provide tooling to increment minor/major changes of version numbers of bundles
• Can the update manager be parameterised to allow arbitrary information (such as licence keys or authentication information) to be passed for dynamic update sites?
• What about using Atom as a standard container for notification of updates?
• What's the level of overlap with Maven and its repository structure? Could the dependency information from either OSGi manifest or Maven's pom.xml be used to derive dependency for any kind of update?
• Apart from how bundles are updated, how are they discovered in the first place? Would there be central registry services that provide indexing (ala Google) whilst still farming out the location of the individual Jars to other sites? (This can be done to a certain extent now; the location of the site.xml and the location of the Jar don't need to be located on the same server.)

One interesting point mentioned by Jeff was that there's already plans for a centralised bundle repository called the OBR (OSGi Bundle Repository), available at bundles.osgi.org which aims to provide centralised searching of bundles and associated information. There are some bundles provided there, but the search could use some work and a couple of the bundles I clicked on received 404s. Maybe as Eclipse grows, particularly for public releases, versioned bundles will get registered there as a matter of course.

The conclusion was to take the rest of the conversation on to the Eclipse mailing list for platform-update-dev and to explore other ways of being able to improve the updates. The good news is that there does seem to be both community interest in these problems, and hopefully we'll be able to make some progress in the post 3.2 timeframe.