Simon - apologies I've been away from this for the last week...
[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?
Actually I see that the plugins responsibilities are a disjoint set -
meaning that the plugins are unconscious of the value of their content
and are used only as a way to bang a bunch of libraries together in
a predictable manner and correctly initialize/deinitialize them.
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.
+1
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.]
So there's two roads - one where one must be explicit about the content
of the plugin in terms of architectural artifacts, this is the manifest
style approach, and the other, where the plugin initialization code does
the necessary registrations of architectural artifacts. These are not
necessarily incompatible approaches either.
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?
AFAIK OSGi is still Java only and a Google search didn't turn up much
that
was useful. In terms of existing technology, I'm not familiar with any
technologies along this line that are open. That being said, a C++
version
of OSGi would be a beautiful thing :)
My gut feeling is that plugin/extension should be decoupled, but the
only
strong point I can see for it in the current architecture is the fact
that
databindings are not explicit as an extension - there is scope for
say an
interface.mumble that has databindings of say XMLBeans or JiBX. If the
databinding can be an extension in its own right, then maybe the
simplifying
assumption of plugin == extension may be the way to go. From the
point of
view of deployment, there may be a greater need for a non-extension
plugin
to package application code to be 'deployed'. Maybe we should have that
conversation about deployment now?
cheers
--oh
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
