His immediate reaction on the OSGi topic was; "I don't see much use for OSGi on the server, but it would be great to have it in the client.". It was largely about updates, plugins and successive download (not the whole client in one go).
Interesting. OSGi was created for the embedded space, so that leans more towards server in my mind (most J2EE servers if not all are OSGi under the covers somewhere these days). Client space is somewhere I don't think we should go anyway, because Eclipse has that space well covered both on the desktop (and more and more convincingly as time goes on) on the web, IMHO. My suggestion of distributing OSGi as a "server bundle" actually has no impact on Pivot as a client at all - OSGi is just used a mechanism for exposing HTTP resources and Pivot is just used as a View layer for sending control messages to the server. In fact, by only depending on the core and compendium spec APIs Pivot could be used as a UI for any OSGi container. However, Felix may expose some additional functionality which it might like Pivot to expose also. This would tie it down to Felix - but I'm OK with that since we're all in the Apache family. :) Cheers Chris 2009/7/2 Niclas Hedhman <[email protected]> > On Thu, Jul 2, 2009 at 3:13 PM, Christopher Brind<[email protected]> > wrote: > > > While we're at it, a quick thought about that OSGi Jira issue that was > > raised a while back - personally I don't see much value in adding OSGi to > > Pivot (I think it might be difficult to reverse engineer OSGi in at this > > stage and Pivot seems modular enough, as well as the argument about who > > needs dynamic services in a UI like which Pivot is design for), > > That is actually an very interesting point. I spoke to Rickard Oberg > yesterday about our Qi4j progress, and both OSGi and Pivot came up, > although separately since he is getting quite far with the > implementation of an application on top of Qi4j. His immediate > reaction on the OSGi topic was; "I don't see much use for OSGi on the > server, but it would be great to have it in the client.". It was > largely about updates, plugins and successive download (not the whole > client in one go). > > I think that Pivot should stay OSGi-independent, but be OSGi-friendly. > This is the strategy we are trying at Qi4j. In Pivot, I think that > should mean that your jars are OSGi deployable bundles, and that the > classloading process is well understood and compatible with OSGi's > protected classloading mechanisms. Since you guys do classloading > (unlike Qi4j), I think your challenge is fairly elaborate, as you will > need to figure out how to communicate unknown classes from client code > to your Pivot bundle, which won't be able to load classes it doesn't > know of in advance. The problem is common, and a couple of solutions > are available, some worse than others, but if you don't develop with, > and have a the demo deployed under, OSGi it will be hard to keep up to > sync. > > > Cheers > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/2qq9er > I work here; http://tinyurl.com/2ymelc > I relax here; http://tinyurl.com/2cgsug >
