The obvious one is Bundle management: - Install - Start - Stop - Update - Uninstall - Refresh (the framework to update package wiring)
However, these might have slightly different requirements depending on whether Pivot is managing a Felix container 'locally' or 'over the web'. For instance, where do bundles that are installed via the web go? If a bundle installed via the web is then 'updated' does that mean a new version has to be uploaded? (An update usually just reloads the bundle from it's registered location). Also, 'over the web' implies some security might be required (but this could be added modularly, read on...). My next priority would be a LogReader implementation (i.e. being able to view calls LogService) and then next possibly a view of how bundles/packages/services are wired. If you look at the OSGi core spec (i.e. minimum required for a container to run and very small/well focused) and the OSGi compendium (i.e. optional stuff, still well focused but somewhat larger) there's plenty of scope for things that can be done (e.g. User Admin, Preferences management). The stuff I mention initially would be 'quick-win'. The Javadocs are also as revealing, though it's not as clear what is core and what is in the compendium. Generally the framework package is the 'core' stuff (yes, 11 classes and a bunch of interfaces) and everything else is from the compendium, I think: http://www.osgi.org/javadoc/r4v41/index.html One thing though, Pivot is obviously aimed at Java 1.6 now - OSGi tries to maintain compatibility with Java 1.3. I think a lot of people abandon that compatability in favour of 1.5+ anyway these days, especially when not dealing with embedded systems, so that shouldn't really be an issue as long as people are aware of Pivot's requirements. That said, management via the browser is obviously running in a different JVM to that of the OSGi container so could be 1.3 compatible if we really wanted it to be. 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), but the idea of using Pivot as a front end for a container is quite appealing and I'm thinking that bundles might be able to contribute to a Pivot UI by exposing WTKX resources via HttpService... This is basically the approach I took with Solstice (my Flex thing). Bundles could contribute to Solstice's UI by exposing SWF modules via HttpService and being marked up with a 'Solstice-UI' manifest header to let the rest of the system know they have something to contribute. Another manifest header, 'Solstice-Type' which could have a value of 'Admin' or 'App' or 'Module' specifies where that bundle is contributing to the UI. Admin means add this contribution to a new tab on the admin interface, App is a high level selectable application and Module represents something that can be loaded by 'applications'. Having learned a lot more about OSGi (and Flex) since then, I would probably take a step-back and re-look at exactly how I did this as I feel it is probably contrived, but I think the principal is valid. What I think we should aim for is a UI for managing Felix, which can then be extended with Bundles without actually having to put a lot of actual OSGi support in to the Pivot code base (if any). I plan on messing around with hosting a Pivot app in an OSGi container (i.e. delivered via the HttpService for interaction via a web browser) over the next couple of weeks anyway (when I get some spare time, gah!) so let me know if there's anything specific you want me to try out. Hope that all makes sense. :) Cheers, Chris 2009/7/2 Greg Brown <[email protected]> > Sounds good to me. I'll ping their mailing list. What might be some > high-level features of such an app? > > > On Jul 1, 2009, at 6:27 PM, Christopher Brind wrote: > > I wrote something to manage to an OSGi container over the web with Flex >> and >> related technologies ... how about a web and/or desktop management >> interface >> for Felix based on Pivot? >> >> Cheers, >> Chris >> >> >> 2009/7/1 Greg Brown <[email protected]> >> >> That is a cool tool. Pivot could work there, but AJAX might be the best >>> choice for that app. It seems to be a tool for searching and presenting >>> documentation, which is what HTML does best. >>> >>> Basically, I'm trying to brainstorm ways that we might collaborate with >>> other Apache projects. Because it has a richer widget set than HTML, >>> Pivot >>> is a great way to build "system management"- type apps. It occurred to me >>> that Maven might be a good fit, but I'm sure there are others. Anyone >>> have >>> any suggestions? >>> >>> >>> On Jul 1, 2009, at 12:34 AM, Niclas Hedhman wrote: >>> >>> On Wed, Jul 1, 2009 at 12:13 AM, Greg Brown<[email protected]> wrote: >>> >>>> >>>> Hi all, >>>>> >>>>> Question for those of you that use Maven: would a Maven repository >>>>> browser/manager application be of interest? I found this: >>>>> >>>>> http://www.mvnbrowser.com/artifacts-browse.html >>>>> >>>>> But I think something built in Pivot might be far more usable and >>>>> useful. >>>>> On >>>>> the other hand, I don't have a lot of experience with Maven, so I'm not >>>>> really sure. >>>>> >>>>> What do you think? >>>>> >>>>> >>>> As a Maven user, I don't think there is much intrinsic value in the >>>> "browse" UI part of it, but the "search". So, I think you need to >>>> explain the bigger picture before I have a better opinion. Do you >>>> intend to convince mvnbrowser.com to use Pivot? >>>> A more interesting product to convince is; http://www.grepcode.com, >>>> but they seem to have invested a lot in the Ajax interface, so... >>>> >>>> >>>> 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 >>>> >>>> >>> >>> >
