On 8/22/06, Oisin Hurley <[EMAIL PROTECTED]> wrote:
[deletia]
js-d says:
>> > 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?
[deletia]
pr says:
> Not sure what the definition of "incompatible" is here. Is it, for
> instance,
> having two separate extension plugins that both provide a
> <binding.ws>? I
> think this is an interesting case and one we should try to support. Of
> course there would need to be some config outside of the Assembly
> specification to determine which one gets used. I see the jave folk
> discussing this very issue.
It's probably the case that we can't define what 'incompatible' means
upfront
except to say that bitter experience will provide :) +1 on being
able to
resolve a choice from a number of binding providers what all can
support 'ws',
I think this is necessary right now, but I'm still a bit
uncomfortable with
<binding.ws> as being too general (not trying to start a new thread
here -
others are looking into this issue :)
[deletia]
>> >>> 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
>
>
> Having tried to retro-fit versioning into many software products
> over my
> many years I would say this is one to think about up front even if
> you don't
> implement it. It is very easy to make it virtually impossible to
> this later
> without majot restructure!
I'm comfortable with starting off using something like a {namespace,
name,
version} triple as a unique identifier for a plugin - or even a {name,
version} pair with the proviso that the name is structure ala java
package
names, eclipse plugin names etc.
We can start off with the basic resolution approaches of exact-match and
latest-match on the version part and then later on develop at-least-
match
and range-match if they are really necessary.
I've seen lots of +1s on this thread, which is nice, and I've just found
out that I can edit the Tuscany wiki, so I'll summarize to there -- the
page will be http://wiki.apache.org/ws/Tuscany/TuscanyCpp/
PluggableCppRuntime
it'll be later today before I get to it.
cheers
--oh
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi guys
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.
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. So we need an API that allows either the model
to be updated or the extension to he scanned for additional information on
load. Conversely we should be able to inject information into the extension
based on model configuration. It may be useful to instigate a model of
extensions in the C++ core/model (the manager thingie) as a place where this
system interface can be controlled.
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?
I don't object to having multiple processes. It could be a real help with
extensions that assume different models of operations, for example, PHP
always assumes a one shot approach to processing requrests. Services/objects
are not maintained across calls. However having said that I'm not sure that
the infrastructure requirements differ a great deal as we switch from a
single process to multiple processes. The control points do though. Maybe it
comes down to the hosting abstraction.
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?
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.
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 :)
I would extend the extra requirement added by JSD to include all runtime
error, logging and audit requirements.
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.
Regards
Simon
