Re: [ecf-dev] OSGi-ECF-Mgmt-Ui-Vaadin - Regions

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Florian,

On 3/14/2015 9:30 AM, Florian Pirchner wrote:

Hey,

i am working on the Vaadin UI for the ECF Management Repo [1].

Right now i have to make some base design decisions. I explored the implementations and tried to figure out, how to map to UI.

Now I am going to start with a first Vaadin component. A component to manage BundleMTO. The component will use the ecf.mgmt.IBundleManager. It offers a method #getBundles().

And here i need to make the first very common design decision.

#getBundles() is related to the bundleContext it is called from. There is the "OSGi subsystem service spec", the "region implementation by equinox" and the hook-services defined by OSGi core spec. These specs and implementations may influence the visibility of bundles, services, events,... 

And the visibility of bundles depends on the context (bundleContext) #getBundles is called from.

Although it's true that the subsystem spec, the region impl, and hooks are bundle scoping mechnanisms, they all aren't actually defined by the core spec.  Generally speaking they are additional/layered specs.  I would expect additional management APIs for these additional specs.  For example, there are currently separate management APIs for in the OSGiRemoteManagement repo for SCR/DS, RSA, OSGi Applications, as well as P2, ECF core+shared object, and extension registry.   The notion here is that just like any given runtime, the management APIs and impls are modular...allowing as many of them to be used as is required.

My inclination is to continue this modularization of the management API as well, and if/when management services are needed for the subsystem spec, regions, and hooks that they be added...as separate new modules with new service APIs (e.g. ISubsystemManger or IRegionManager, or IHookManager, etc).   These specific managers for these extenders don't exist yet, but I can/will help with their definition and implementation.

My question to you all: "How may a common UI for bundles look like, to reflect the issues above?"

What I would personally like to see is some sort of user interface structure that can/could also be modularized, so that it was extendable as new manager APIs were introduced, without having to reimplement existing UI.   I'm not a e4/UI expert like many of you, so I won't presume to describe how this should be implemented in e4, but perhaps using the extensibility provided by databinding and/or IWorkbenchAdapter...which along with a general content provider impl and use of IAdaptable could allow such additional manager services be introduced without fundamentally modifying the presentation of (e.g.) the information provided about a running framework by IBundleManager/IServiceManager, etc.  That's the way I've been thinking of it...fwiw...I know that for example the Project Explorer UI has some of these abilities for extension/addtion...although I don't know if that approach is relevant for a UI like this and it was mostly implemented after e4 (I think).

In my opinion components to manage (display) bundles (and services) need the bundleContext as an input. Only if the "input bundleContext" is known, the visible bundles can be displayed. If input is null, then the "framework bundle (id==0)" should be used.

I don't agree about that.   the direct handle to a BundleContext implies local-only-provided functionality...and further for security isn't ideally 'passed around'...especially to some remote management agent (even if you could do that...which actually would be very hard).

So i am thinking about a Master-Detail architecture.

The master shows all bundles visible to the "framework bundle (id==0)". If a bundle is selected in the master table, by a combo box or even by event admin (selected bundleContexts will be published by event admin), the detail view shows all visible bundles for the selected bundleContext.

I don't have any problem with your notion of a Master-Detail architecture on the face of it, but I guess I'm not completely clear yet what you mean by that.

And it should also be possible to select regions i guess. So "show all visible bundles for region x".

My question is this:  what can we do initially that would work if the target framework is...e.g...Karaf running on Felix (where no region exists), or Concierge running on a RaspberryPi?   What I'm getting at is that I think we want both the management APIs *and* the UI/presenation to be modular and extensible, so that relevant parts can be used on multiple frameworks/implementations, and configurations (e.g. with and without regions, with and without SCR, with and without RSA).  I know this is a challenge, but I do think it's worth doing...because I expect there are lots of people that would like mgmt UI and remote mgmt for many frameworks that may not include region support, p2 , subsystems, ecf, rsa, scr, etc. 

In short:

A bundle component that shows all visible bundles.... 

• needs a master showing all bundles by framework bundle

The current impl provided by org.eclipse.ecf.mgmt.framework.host.BundleManager uses the bundleContext of the BundleManager instance registered on the host.   It would be a trivial registration-time change to use bundle[0] bundleContext instead, but I actually think that the having it be the bundleContext of the BundleManager instance (determined at service registration time) as the default makes a lot of sense.  As it is now, the bundleContext of bundle 0 could actually be used at BundleManager registration time...which would give you exactly what you are asking for.  Another point:  perhaps a future ISubsystemManager would/could use multiple IBundleManager instances (one for each subsystem).

• detail components needs to use an "input bundleContext" to determine all visible bundles filtered by issues above

To my mind what would be best is if a future ISubsystemManager exists that the UI could be extended to do the filtering as you describe...based upon use of the ISubsystemManager (and/or IHookManager, IRegionManager, etc).

• if the input context is null, the system bundle is used to show bundles

Again as it is now the host/service impl actually can/does determine which BundleContext is used.

• components should provide a possibility to select the "input context" by an Ui selection element displaying all bundles based on the "framework bundle"

I think that architecture should meet all possible usecases. Inputs are very welcome.

I agree that an architecture should be flexible and extensible enough to meet as many use cases as can be imagined :).  But given that there are multiple optional 'extenders' to the basic framework (including RSA, but also including regions, subsystems, SCR, hooks, etc)...and it's not impossible that there would/will be others that are not yet defined (future specs), I think an approach that creates distinct management APIs...separated from impl as the org.eclipse.ecf.mgmt.* APIs are...that can optionally used, layered, and introduced later allows for the handling of multiple use cases.  It also does allow simplification (each of the org.eclipse.ecf.mgmt.* APIs is actually pretty small/simple/understandable and this is a nice thing also).

Thanks.  FWIW I think this is a great discussion. 

Scott