On 8/22/06, Oisin Hurley <[EMAIL PROTECTED]> wrote:
Hi Simon,
> Had a long weekend so just picking up this thread. Looks like a really
> useful discussion and I too like the requirement driven approach. I
> have a
> few to add/comment on. It seems that a plugin resolves to a
> component type
> or binding, i.e. what the assembly model refers to as extensions,
> so that is
> what I have in my mind.
IMHO you can package an extension as a plugin, but you can also package
an extension as >1 plugin, or you could package a number of extensions
in just 1 plugin. So I think there should be a level of decoupling
there...
Intersting...
6. There will need to be some kind of manager thingie to keep
>>>> track of plugins and their state at runtime.
>>>>
> Extensions should be able to constribute information to the in
> memory model,
> for example, via annotations.
[deletia]
...and this is why :) There are number of responsibilities of an
extension - which you accurately describe - and there are a number
of responsibilities of a plugin, related to configuration and lifecycle
and I think it would be a Good Thing to keep them as separate
development
efforts. What do you think?
Do you mean that a plugin may have responsibilities that are a sub-set or
super-set of those of a particular extension?
We could probably have the same conversation re. deploying components and
composites into the C++ SCA infrastructure as opposed to deploying parts of
the C++ SCA infrastructure.
Maybe we need to be a bit more explicit about what we anticipate being in a
plugin. For examle,
0..n Component type container implementations
0..n Binding implementations
0..n Host adapters
[0..n Components
0..n Composite(s) should these be included as well? Seems unlikely that you
want to deply at the same time but you will want to deploy at some time.]
Can we use exsiting technology for some of this, for example, there has been
much discussion of OSGi on the java list, is OSGi wider that just Java now?
[deletia]
>> +1 for a simple lifecycle interface. What kind of parameters do
>> you have
>> in mind?
>
> Will also need some hosting abstraction to tie in with these lifetime
> interfaces, for example, it might be useful for an extension to
> know when it
> can observe caching semantics. Also has an impact on the (re)
> deployment
> story, for example, we may want to deploy extensions without
> stopping the
> server so we need to be able to do this and have the extension come up
> cleany. These don't need to be at the top of the list.
+1
[deletia]
> I would extend the extra requirement added by JSD to include all
> runtime
> error, logging and audit requirements.
+1. On the subject of audit, to do successful auditing we need to have
access to the concept of an identity :) Has there been any discussion
about this already?
We probably need something based on the exposed service identities + the SCA
context within that + information from the security context but I haven't
seen it discussed. I've only seen identity discussed in the context of
conversations in the SCA specs.
Oisin, good idea to put all this up on the wiki. I'll check there
> when you
> have added you first tranche and add comments in.
Will email the list when it's in place.
cheers
--oh
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
