Comments in line. Have read and will respond to Greg's comments too. 2009/3/25 Todd Volkert <[email protected]>
> 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. > Sure. =) > > > 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? Once you get your head around OSGi the questions you'll be asking are: - right, where do I put my bundles? (though technically they can be anywhere on the file system) - how do I manage my bundles? (i.e. install/start/stop/update/uninstall) In Equinox (and Felix I think) you can issue commands at a command prompt provided at the console and Knoplerfish provides a UI. Then you get in to things like where the various frameworks store data for bundles, do they unpack the jars somewhere, things like that > > > > 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. It sure is an interesting model. However, must remember to be careful with the use of "OSGi" as it is a trademark of the OSGi Alliance and they do protect that trademark. Basically, If we're not using actually using the OSGi spec, we can't mention it. > > > > 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... > There's no reason why we couldn't create a bundle that implements the Preferences API but in the background delegates to another mechanism (the Preferences stuff that Greg mentions in his mail, for instance). I'm certainly excited about the prospect of OSGi enabling Pivot. It certainly works for other UI frameworks (namely Eclipse). Cheers, Chris
