Hi guys,
I like this requirement based approach, a few +1, comments and questions
below.
Pete Robbins wrote:
Hi Oisin,
Here's the dumb question: What do you mean by "Plugin"? Is it a
composite or
group of composites?
Cheers,
Or just a set of extensions packaged in a library that you plug into the
runtime?
On 17/08/06, Oisin Hurley <[EMAIL PROTECTED]> wrote:
Hi guys,
I thought I might kick off a thread on pluggability in the C++
implementation to get some ideas rolling around, so while these
are not 'requirements' at all, they might eventually lead to
some ;)
1. Language independence is not an issue here, so all plugins
are described and implemented in C++.
+1, a plugin may want to integrate pieces of code in another language
but it always integrates with the Tuscany runtime through C++.
2. It should be reasonably straightforward to make a plugin
with minimum code, so things like base plugin classes as part
of the core are a good thing.
+1, plugins should not be exposed to details of the runtime or
interactions that they don't need to know about. Also I'd like to keep
the base "plugin" classes as thin as possible, they would be interfaces
if interfaces existed in C++.
I'll add a few more requirements here :)
The extension programming model should be easy to understand by people
who have read the SCA spec. Using consistent terminology (e.g. an
"implementation" plugin/extension contributes the support for a
particular component "implementation" type) will help. Also the model
used by the developer of an extension should be consistent enough with
the model described in the SCA spec. The in-memory model describing SCA
assemblies can be optimized for use by the runtime, but it should be
easy to grasp by the guy who just read the SCA spec and just understood
what a composite, component, service or reference are.
3. Plugins can be loaded on-demand, from dynamic libraries,
and many plugins can be put into a library.
Do you really mean multiple plugins in a library? or one plugin per
library contributing multiple extensions? I guess this depends on what
we mean by plugin :)
4. Plugins can be statically linked with an application.
Could you describe the use case you have in mind? Does that apply to
just plugins? or the whole runtime?
5. Plugins should be evictable too, provided that this feature
is supported on the target platform.
6. There will need to be some kind of manager thingie to keep
track of plugins and their state at runtime.
I've been thinking about this and wondering what the architecture of the
runtime will be with many different plugins? Are you guys envisioning
one big process with different (maybe incompatible?) libraries loaded in
it? or a more distributed architecture with multiple processes?
I must admit I've been toying with the idea of having multiple processes
handling the various component implementation types and binding types,
then it would be quite easy to bring them up/down... What do you think?
7. Plugins need to support an interface for initialization
and shutdown at the least. There will need to be some kind
of simple lifecycle put together. Request for lifecycle
transitions will need to support parameters
+1 for a simple lifecycle interface. What kind of parameters do you have
in mind?
8. Plugins have names. Easy.
+1
9. Plugins have versions, and dependencies on other plugins too.
We may want to get there at some point, but I was not sure that we
really needed this to start with... Would it make sense to stage this
and start with a simple solution with no versions and no dependencies,
and get into the whole versioning / dependency / coexistence of multiple
versions etc. later?
10. Plugins describe and can validate their own configuration.
+1, I like the idea of having plugins describe their own config and
handle the validation. Are you talking about things that the installer
or system administrator can configure, for example the python
implementation extension will look for scripts in a specific directory,
which needs to be configured? or are you talking about configuration
described in SCDL documents?
11. Plugins need to be signable, or equivalent.
May be a dumb question, but is this different from signing the core
Tuscany runtime?
Comments?
One more requirement... Our pluggability story should cover the
following additional aspects:
- validating SCA application artifacts (for example an
<implementation.python> element in a .composite file) and reporting
errors in a meaningful way (the python extension should tell the
application developer that the python script he specified in file
sample.composite on line 23 cannot be found)
- contributions to any codegen / build / install / configure steps
required to get the particular implementation, binding or policy working
- contribution to our administration and monitoring story, which still
needs to be defined :)
--oh
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
