Great background information, Chris - thanks. My comments below. >> There are quite a few implementations out there already, so we would need a >> very strong reason to re-implement it from the ground up. The obvious first >> port of call for this project is Apache Felix since it is an Apache project: >> http://felix.apache.org/ > >I like the idea of exploiting the synergy created by us both being >under the Apache umbrella.
Agreed - we should definitely explore this further. >>An Eclipse plugin usually has a plugin.xml in >>it and this declares extension points and defines which extensions are >>provided by the plugin. The registry watches bundles being installed and >>reads the plugin.xml from the bundle if it is available. This seems like a great use case for annotations. I wonder how Felix handles this. >> Also, while OSGi is quite lightweight for building command line, desktop or >> server apps (e.g. the minimum requirement bundle for Equinox ways in at >> 994k) to me that still feels a little heavy for the starting position for an >> applet based application. Then again, perhaps Felix or Knoplerfish have >> smaller footprints, that is very possible. >Good point, though two things come to mind that might mitigate this. >First, I've been thinking that we might want to start thinking about >the concept of a "Pivot kernel" that can show the loading state of an >app while the JARs are loading, to eliminate the unresponsive feel of >the app while it initializes. I think that an application that is structured as a collection of modules would benefit from such a "kernel" approach, but I wouldn't want to impose it on all applications. Perhaps the kernel could simply be an implementation of pivot.wtk.Application that provides module startup services. >Second, we could fall back on the >"recommended only for Web Start deployment" answer, in which case the >large file download feels more natural since you're launching a >desktop app... Applets can also be deployed via JNLP in J6u10+, but the JNLP persistence API might still be the best approach since it won't require signed code. The Preferences class currently under development also takes this approach.
