[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-tm-dev] Extension to RSECoreRegistry: Dynamic system typeprovider extension point
|
Moved this into bugzilla, lets continue discussion
there:
Added this comment:
I basically like the idea of contributing system types
dynamically, although I wonder subsystems would register against a dynamically
contributed system types. For me, it looks like this proposal calls for a change
to dyanmically register subsystemConfigurations as well.
Like with all dynamic contribution, I'm wondering whether
an API might be more applicable than an extension point. There might be some
kind of generic "earlyStartup" extension point, which is called just before RSE
uses any system types. This code could then call RSE API to inject the new
systemTypes (e.g. SystemRegistry.addSystemType(...). That much for discussion -
I'm not convinced that such API is better than an extension point in this case,
because of timing considerations (systemTypes need to be available VERY
early).
I think that Eclipse Platform also has some examples where
they allow both static and dynamic contribution of some elements, this should
perhaps be checked.
If we go with the extension point, I'd recommend extending
the current "org.eclipse.rse.core.systemTypes" extension point rather than
defining a new one. The current extension point could contain a sequence of
(optional) "systemType" tags AND a sequence of (optional) "systemTypeProvider"
or "systemTypeFactory" tags.
Cheers,
--
Martin Oberhuber
Wind River Systems,
Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
It sounds good to me.
____________________________________
David McKnight
Phone: 905-413-3902 , T/L: 969-3902
Internet:
dmcknigh@xxxxxxxxxx
Mail:
D1/140/8200/TOR
____________________________________
David Dykstal
<dykstal@xxxxxxx>
Sent
by: dsdp-tm-dev-bounces@xxxxxxxxxxx
02/02/2007 08:34 AM
|
Please respond
to
Target Management developer discussions
<dsdp-tm-dev@xxxxxxxxxxx> |
|
|
To
| Target Management developer
discussions <dsdp-tm-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| Re: [dsdp-tm-dev] Extension to
RSECoreRegistry: Dynamic system type
provider extension point |
|
Kushal and Dave --
The registry is mostly yours. On the face of
it this sounds really
good. What do you think?
--
Dave
On Feb 2, 2007, at 7:16 AM, Stieber, Uwe wrote:
>
Hi,
> I would like to extend the RSECoreRegistry to accept system types
from
> other source than the system type extension point only.
Contributors
> willing to contribute system types dynamically, can
register
> IRSESystemTypeProvider implementations via an additional
extension
> point. The IRSESystemTypeProvider does have exactly one
method:
>
>
IRSESystemType[] getSystemTypesForRegistration();
>
>
System type contributions from the system type extension point have
>
higher priority and will be read always before the
>
IRSESystemTypeProvider will be called. System Types from the
>
IRSESystemTypeProvider conflicting with a contributed system type
>
(having the same id) will be not accepted and are skipped. The
>
IRSESystemTypeProvider is responsible that calls to
>
IRSESystemType.getProperty(...) are correctly mapped for the 3 public
>
system type properties as defined in IRSESystemTypeConstants. From RSE
>
point of view, absolutly nothing will change from API point of view,
>
RSECoreRegistry.getDefault().getSytemTypes() is returning the full
> list
> of registered system types, with or without this
extension.
>
> The purpose of this extension is to allow adaptors
of RSE to generate
> RSE system types dynamically from existing similar
objects in their
> existing product. It decreases the administrative
effort to initial
> jump
> on top of RSE and helps
maintaining existing contributions to the
> adapted product. Furthermore
it reduces the complexity of contributing
> to the adapted products
which will definitly reduces the possible
> sources of errors and
frustration which in turn is essential for the
> acceptance level of RSE
itself (for adaptors) and RSE based products
> (for
contributors).
>
> In our specific case we want to keep the impact
of switching our
> product
> to RSE for existing internal
and external contributions at absolute
> minimum. Being able to
contribute system types dynamically keeps our
> existing contributor
base happy and their contributions working for
> our
>
product prior the switch to RSE and for our products after the
>
switch to
> RSE. It is not required for them to maintain multiple source
bases to
> support the full range of product versions still being in
maintenance.
>
> PS: This very small impact extension solves
basically the bugzillas
> 170918 and 161193 ...
>
>
Committers: Any comments?
>
> Best regards,
> --
> Uwe
Stieber
> Member of Technical Staff
> Engineering - Wind River
Systems - Austria
>
_______________________________________________
> dsdp-tm-dev mailing
list
> dsdp-tm-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
_______________________________________________
dsdp-tm-dev
mailing
list
dsdp-tm-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
