Re: [C++] Requirements for a pluggable C++ Tuscany implementation

[Oisin Hurley]

[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]