[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] OSGi-ECF-Mgmt-Ui
|
Hi Florian,
On 3/14/2015 12:34 PM, Florian Pirchner wrote:
Hi there,
now i dived deeper into the MTO structure.
And would like discuss an issue.
Wouldn't it be a good idea, to enrich the MTOs. For instance, the
BundleMTO does not provide the start level. So an additional service
request for each bundle to IBundleManager#getBundleStartLevel() is
required to get the BundleStartLevelMTO.
Indeed, the bundle and its start level are separated by the spec. But
for the management UI it would increase performance, if we could
reduce server request. Specially if the mgmt.framework is provided by
RS or RSA.
This is a great question. The reason things are the way they are
currently wrt start level info and bundles is essentially because of
what you say above: the bundle and it's start level are separated by
the spec.
But you are quite right that it *might* make sense to...in some
cases...provide more information (like startlevel, etc) in the MTOs.
(BTW, MTO stands for 'Management Transfer Object'...which is a variant
of 'Data Transfer Object'...now used in the OSGi specifications (R6).
It is quite possible that you are right Florian, in saying that for most
management use cases it would make sense to include the Bundle start
level information. But to be honest with everyone, I'm not yet sure
that's the case (that most management use cases would require or even
imply showing the bundle's current start level by default/without
additional services).
We can/could/will add/enhance the MTOs...via adding fields (like bundle
start level), and/or sub-classes, etc. Whatever makes sense. But I
think it does make sense to get some more management use case experience
to determine whether or not to do this. Note that I've already broken
this rule WRT BundleMTO even though it's not part of the OSGI-specified
BundleDTO, I do include the bundle's manifest contents in the
BundleMTO. That one seemed pretty obvious to me :).
But again...I have no objection to adding information to MTOs (and/or
extending them) when we can show that it makes sense. I just would
like to keep things as simple as possible to start, and add things as we
find through usage that it's necessary. Adding things is so much easier
than deleting them...at least when it comes to API :).
A similar example is BundleWireMTO. providerWiring and requirerWiring
returns an int value for the wiring. Maybe we could preload things in
the manager host and return WiringMTO instead or additional.
Yes that's true...and may make perfect sense. Truth is that I'm not
sure, and so to get things started I did the simplest possible (and
pretty-closely mirrored the OSGi-standardized DTO structure...at least
WRT the wiring API).
Maybe that is not possible for reason. But i would really appreciate
these changes.
It's possible...but I would really like to get some of the basics in
place and get a little experience with usage and use cased before adding
to many things...assuming that those things/that information are going
to be required 'greedily' as opposed to 'lazily'.
If you (Scott) accept these enhancements, then i would love to
implement them.
I have no objection to other people adding things to the
org.eclipse.ecf.mgmt.* APIs, and I've tried to structure things so that
this is natural (i.e. modular and extensible). For example, note that
all the *Manager implementations implement IAdaptable, meaning that they
are already structured to provide adapters at runtime. I've also
defined most of the host impl methods to be protected (or public if part
of service api of course).
But I would like to try to get some usage experience...before adding too
much. I just feel that's a good modular way to go :).
Scott
