Wow, thanks Chris; this is an great entry point! My comments/questions are inline.
> I work with OSGi all the time so this sounds very appealing to me. Once this is scoped, if you're willing to tackle this, that would be awesome. > In order to use OSGi, we would have to find or build an implementation. I strongly vote "find", unless there's a real compelling reason that we have to build our own. The only reason I could think of is if we'd want a trimmed down version that suits our needs only and has a very small footprint. > 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. > But I strongly recommend that people play around with these as well: > Equinox (the implementation Eclipse is built on) : > http://www.eclipse.org/equinox/ > Knoplerfish: http://www.knopflerfish.org/ This seems like a daunting task given my lack of OSGi experience. Do you think you'd be able to easily discern the relative strengths and weaknesses of these three projects? > IMHO, The > Extensions and Extension Points approach is more suitable to building UIs > based applications than using the service registry and this is exactly how > the majority of the Eclipse IDE hangs together. Agreed. I built an extension and extension point API in a JavaScript library (around a "fake" OSGi layer), and it's a great way to structure applications. > One problem that immediately springs to mind is that one of the core things > that OSGi provides is a data area, somewhere that bundles can read and write > files. This maybe a problem for Pivot since it will often be running in a > sandbox with strict security policies. As such, it maybe that we need to > modify whichever framework we base our work on in some way, but then we > potentially don't have an OSGi compliant container. I'll have to re-read > the spec to work out what we can get away with. Might we be able to use the preferences API, or is that too limiting? We could also say that if you choose to use Pivot OSGi support, you must either run in a signed applet or a JNLP configuration with the <all-permissions/> security model. Larger applications necessitating modular design will probably want native read/write access anyway... > 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. 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...
