Pete Robbins wrote:
Hi Oisin,
Here's the dumb question: What do you mean by "Plugin"? Is it a
composite or
group of composites?
Or just a set of extensions packaged in a library that you plug
into the runtime?
'Plugin' means a piece of software that adds some functionality in the
form of a core extension or an application element. So yes I think it
would work to have a composite bundled as a plugin - it also would be
a nice idea to have say <binding.ws> bundled as a plugin too. Lots of
scope - just the plugin mechanisms need to be clear, an SPI type of
thing needs to be in place and of course (the interesting piece ;) a
collection of shlib loaders for all the target platforms.
At this point I declare my allegiance to Darwin/powerpc :)
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.
+1
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.
For 'consistent enough' it would be good to say 'as consistent as
possible',
make it a bit stronger, otherwise +1
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 :)
Multiple plugins in a library is the goal to be aimed for in the
long term, IMHO, the reason being it makes it really easy for an
extension provider to package everything up into one lib - so if
you have (for example) <interface.idl>, <implementation.cxx.poa>
and <binding.iiop> then you can just deliver them all as libcorba.so
and all will resolve gracefully.
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?
I'll 'fess up and say that I have no particular use case in
mind right now. When I was writing that line, I was thinking
of 'embedded' applications - not in the sense of 'embedded
systems', although that might be an option for router hardware -
but in the sense of an SI constructing and provisioning a
system that uses Tuscany buried deep in folded layers of fat
application code. The Tuscany runtime is meant to stay buried,
and having a statically linked binary is an effective way to
do that -- it bakes the version in so that if a newer version
of Tuscany gets installed with shlibs, the old version won't
pick anything up by accident. Not a very strong case :)
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?
It's late here and my brain is a mite melted, but I think I
can see advantage to both :) In the first case, I think that
having incompatible libraries cohabiting a process should be
ruled out of order, but it should be possible for example for
an application to be able to take advantage of multiple binding
extensions in the same process - this seems like a reasonable
expectation if you are writing something that is going to work
as a bridge, for example.
If I understand the second case correctly, you're thinking of
having separate processes for a {binding, implementation} pair
or something like that, rather than using IPC between binding
and implementations? If thats the case, that seems ok to me :)
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?
I'd go for a simple context-stylee thing with named properties
and simple typing. A bit of a step up from const void* const *
and pleasantly debuggable :)
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?
Simple solution, followed by dependencies, followed by versioning
would work for me. We can learn from what OSGi does in terms of
its management of these things and maybe emulate it to some extent.
So: +1
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?
What I'm specifically thinking about here is that each individual plugin
takes responsibility for owning and validating it's own
configuration. The
involvement of the core is limited to the provision of a configuration
resolver chain at initialization time - so you tell the core where it is
to find configuration artifacts (be they scripts, SCDL, certificates,
whatever) in a path-like manner, and the plugins themselves check to
see if there is something there for them, and if it is correct.
There's lots of things I like about this approach, but one of the most
excellent ones is that you can go develop a plugin, develop your config
schema and *clearly document* the configuration elements. This is a
really big deal, even though it might sound obvious :)
11. Plugins need to be signable, or equivalent.
May be a dumb question, but is this different from signing the core
Tuscany runtime?
Yes, I think it is, because you might decide to go off and download
a library from somewhere else and plug it into your runtime. These
are binary artifacts, and hard to read :) So some sort of signing
may give you the confidence to actual use the plugin and reduce
concern about your network being suborned as a result.
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)
+1
- contributions to any codegen / build / install / configure steps
required to get the particular implementation, binding or policy
working
+1 to decent documentation in this regard
- contribution to our administration and monitoring story, which
still needs to be defined :)
This is interesting. People love writing 'management consoles' that
are neat little fun things for developers, but probably not all that
useful in a real-world deployment where things like EMS integrations
can be more valued. So I'd be slow to go down the road of doing some
new in that regard. However *monitoring* is vital, and I would suggest
that we take a look at some of the approaches that are out there for
composing packets of information that can be read by many tools.
I've a bias here, I admit, but take a look at the Eclipse TPTP
project [0] where they have done tremendous work on the presentation
of monitoring information gleaned in certain standard formats from
runtimes.
cheers
--oh
[0] http://www.eclipse.org/tptp/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
