[C++] SCA Extensions architecture

[Pete Robbins <ro...@googlemail.com>]

I've started playing around with loading extension libraries to support
"other language" extensions and so a wee bit of re-architecture has "cpp"
being an extension language. In other words I'm trying to make a core that
is not tied to cpp implementation. This core will roughly be a model loader
in line with the assembly model spec with extensions for stuff like <
implementation.cpp.. > and a runtime for resolving wiring and locating
services. This is nearly what we have now but without the cpp C&I spec api
implmentation code (anything under runtime/core/src/osoa...).

This will involve a bit of refactoring to remove the unnecessary
dependencies from the "core" to the cpp specific code.

What I expect to end up with is libraries for:
tuscany_sca - the core assembly model and internal message structure
tuscany_sca_cpp - the cpp language extension (extension functions for
loading cpp model etc.)
tuscany_sca_cpp_osoa - the "client" side functions defined by the C++ C&I
spec (ComponentContext etc.)

I'm not yet sure if the latter 2 should be the same library, that will
depend on their interdependencies.

This is not a trivial change and it's tricky to break it down into sensible
small chunks so I may start a branch/sandbox to play in for the moment...or
if it suddenly all works I'll get it checked in to the trunk asap ;-)

It's nearly there but will probably take another day or maybe 2 and it would
probably be good for anyone else interested in the cpp code to review it. It
won't be near perfect but it will provide a good base for a more modular and
extensible runtime.

Cheers,

Re: [C++] SCA Extensions architecture

[Pete Robbins <ro...@googlemail.com>]

On 18/08/06, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> Mmm, not sure. I was thinking that in the case of an extension that I
> would
> want the C++ SCA model to reflect all of the components and associated
> services and references that appear in the SCA configuration (whether that
> be through SCDL or annnontations). Some (or all now you are making C++ an
> extesnions) of the components are represented as extensions. Each
> extension
> has to have some way of interacting with the bindings that C++ SCA
> provides
> so needs to connect into the wrapper/proxy architecture provided. So I
> guess
> what I'm saying is that I anticipated the runtime interface between
> components implemented in extensions and the C++ SCA runtime, in
> particular
> the bindings, to be via the proxy/wrapper route. I some cases the
> extension
> may be able to use the core proxy/wrapper base system natively. In others
> they may want to override it to provide language specific proxies and
> wrappers. I may be talking complete twoddle here so correct me if tI'm
> going
> off on a tangent.


Not twoddle! I probably didn't explain my thoughts very well. I agree with
what you have written above. The "core" has to represent the assembly model
and allow access and extensions to that model. I guess I was just
questioning the proxy/wrapper architeture and thinking it is currently not
generic enough... i.e. it is hard coded to <implementation.cpp>

As an aside I would like to have a mechanism whereby bindings can be
> implemented in either an extension or in C++ SCA. In this way faciliites
> of
> the extension environment can be used without recourse to C++ SCA if that
> is
> more appropriate (what more appropriate means is TBD in my mind at
> present).
> So I have anticiapted that this could be done by allowing the connection
> between extension and core proxy/wrapper representations to be broken. I
> have to admit that this is not a high priority for me just something that
> could be useful down the line


agreed.

Cheers,

-- 
Pete

Re: [C++] SCA Extensions architecture

[Simon Laws <si...@googlemail.com>]

On 8/18/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> Still very much in experimental stage but I recognize your concerns.
> ServiceProxy is an interesting example. It really belongs with the
> implementation.cpp but is currently in the core. Do we need this at all
> for
> other extensions or is there some other representation of the service?
>
> more later...
>
> Cheers,
>
>
>
> On 18/08/06, Simon Laws <si...@googlemail.com> wrote:
> >
> > On 8/17/06, Andrew Borley <aj...@gmail.com> wrote:
> > >
> > > Pete,
> > > Sounds good to me, I'll definately be interested in reviewing if you
> > have
> > > something to show before tomorrow (Friday) afternoon (I'm on holiday
> for
> > > the
> > > week after that). The Python stuff I've been doing will need fitting
> in
> > to
> > > the structure you've put together, so I'd be interested in seeing the
> > > interfaces you're making for the CPP extension.
> > > Once that's in place I guess we'll start looking at binding and
> > interface
> > > extensions, and then there's wiring policies, data bindings, etc, etc
> to
> > > look at!
> > >
> > > Cheers
> > > Andy
> > >
> > > On 8/17/06, Pete Robbins <ro...@googlemail.com> wrote:
> > > >
> > > > I've started playing around with loading extension libraries to
> > support
> > > > "other language" extensions and so a wee bit of re-architecture has
> > > "cpp"
> > > > being an extension language. In other words I'm trying to make a
> core
> > > that
> > > > is not tied to cpp implementation. This core will roughly be a model
> > > > loader
> > > > in line with the assembly model spec with extensions for stuff like
> <
> > > > implementation.cpp.. > and a runtime for resolving wiring and
> locating
> > > > services. This is nearly what we have now but without the cpp C&I
> spec
> > > api
> > > > implmentation code (anything under runtime/core/src/osoa...).
> > > >
> > > > This will involve a bit of refactoring to remove the unnecessary
> > > > dependencies from the "core" to the cpp specific code.
> > > >
> > > > What I expect to end up with is libraries for:
> > > > tuscany_sca - the core assembly model and internal message structure
> > > > tuscany_sca_cpp - the cpp language extension (extension functions
> for
> > > > loading cpp model etc.)
> > > > tuscany_sca_cpp_osoa - the "client" side functions defined by the
> C++
> > > C&I
> > > > spec (ComponentContext etc.)
> > > >
> > > > I'm not yet sure if the latter 2 should be the same library, that
> will
> > > > depend on their interdependencies.
> > > >
> > > > This is not a trivial change and it's tricky to break it down into
> > > > sensible
> > > > small chunks so I may start a branch/sandbox to play in for the
> > > > moment...or
> > > > if it suddenly all works I'll get it checked in to the trunk asap
> ;-)
> > > >
> > > > It's nearly there but will probably take another day or maybe 2 and
> it
> > > > would
> > > > probably be good for anyone else interested in the cpp code to
> review
> > > it.
> > > > It
> > > > won't be near perfect but it will provide a good base for a more
> > modular
> > > > and
> > > > extensible runtime.
> > > >
> > > > Cheers,
> > > >
> > > >
> > >  Pete
> >
> >
> >
> > Count me in too.  Very interested in reviewing the new layout. I'm
> > particularly interested in how you represent the component
> implementation
> > artifact like <implementation.cpp> as I want to understand how we mirror
> > the
> > reference representation in an extension.
> >
> > For example, in your restructuring exercise where is ServiceProxy going
> to
> > end up? I would like some core representation of the proxy (reference)
> so
> > that I can either use this natively or mirror it in user space in any
> > extension I write.
> >
> > Anyhow I guess I need to wait to see the details of what you are
> > proposing.
> > Are you going to be able to talk us through it?
> >
> > Regards
> >
> > Simon
> >
> >
>
>
> --
> Pete



Mmm, not sure. I was thinking that in the case of an extension that I would
want the C++ SCA model to reflect all of the components and associated
services and references that appear in the SCA configuration (whether that
be through SCDL or annnontations). Some (or all now you are making C++ an
extesnions) of the components are represented as extensions. Each extension
has to have some way of interacting with the bindings that C++ SCA provides
so needs to connect into the wrapper/proxy architecture provided. So I guess
what I'm saying is that I anticipated the runtime interface between
components implemented in extensions and the C++ SCA runtime, in particular
the bindings, to be via the proxy/wrapper route. I some cases the extension
may be able to use the core proxy/wrapper base system natively. In others
they may want to override it to provide language specific proxies and
wrappers. I may be talking complete twoddle here so correct me if tI'm going
off on a tangent.

As an aside I would like to have a mechanism whereby bindings can be
implemented in either an extension or in C++ SCA. In this way faciliites of
the extension environment can be used without recourse to C++ SCA if that is
more appropriate (what more appropriate means is TBD in my mind at present).
So I have anticiapted that this could be done by allowing the connection
between extension and core proxy/wrapper representations to be broken. I
have to admit that this is not a high priority for me just something that
could be useful down the line

Regards

Simon

Re: [C++] SCA Extensions architecture

[Pete Robbins <ro...@googlemail.com>]

Still very much in experimental stage but I recognize your concerns.
ServiceProxy is an interesting example. It really belongs with the
implementation.cpp but is currently in the core. Do we need this at all for
other extensions or is there some other representation of the service?

more later...

Cheers,



On 18/08/06, Simon Laws <si...@googlemail.com> wrote:
>
> On 8/17/06, Andrew Borley <aj...@gmail.com> wrote:
> >
> > Pete,
> > Sounds good to me, I'll definately be interested in reviewing if you
> have
> > something to show before tomorrow (Friday) afternoon (I'm on holiday for
> > the
> > week after that). The Python stuff I've been doing will need fitting in
> to
> > the structure you've put together, so I'd be interested in seeing the
> > interfaces you're making for the CPP extension.
> > Once that's in place I guess we'll start looking at binding and
> interface
> > extensions, and then there's wiring policies, data bindings, etc, etc to
> > look at!
> >
> > Cheers
> > Andy
> >
> > On 8/17/06, Pete Robbins <ro...@googlemail.com> wrote:
> > >
> > > I've started playing around with loading extension libraries to
> support
> > > "other language" extensions and so a wee bit of re-architecture has
> > "cpp"
> > > being an extension language. In other words I'm trying to make a core
> > that
> > > is not tied to cpp implementation. This core will roughly be a model
> > > loader
> > > in line with the assembly model spec with extensions for stuff like <
> > > implementation.cpp.. > and a runtime for resolving wiring and locating
> > > services. This is nearly what we have now but without the cpp C&I spec
> > api
> > > implmentation code (anything under runtime/core/src/osoa...).
> > >
> > > This will involve a bit of refactoring to remove the unnecessary
> > > dependencies from the "core" to the cpp specific code.
> > >
> > > What I expect to end up with is libraries for:
> > > tuscany_sca - the core assembly model and internal message structure
> > > tuscany_sca_cpp - the cpp language extension (extension functions for
> > > loading cpp model etc.)
> > > tuscany_sca_cpp_osoa - the "client" side functions defined by the C++
> > C&I
> > > spec (ComponentContext etc.)
> > >
> > > I'm not yet sure if the latter 2 should be the same library, that will
> > > depend on their interdependencies.
> > >
> > > This is not a trivial change and it's tricky to break it down into
> > > sensible
> > > small chunks so I may start a branch/sandbox to play in for the
> > > moment...or
> > > if it suddenly all works I'll get it checked in to the trunk asap ;-)
> > >
> > > It's nearly there but will probably take another day or maybe 2 and it
> > > would
> > > probably be good for anyone else interested in the cpp code to review
> > it.
> > > It
> > > won't be near perfect but it will provide a good base for a more
> modular
> > > and
> > > extensible runtime.
> > >
> > > Cheers,
> > >
> > >
> >  Pete
>
>
>
> Count me in too.  Very interested in reviewing the new layout. I'm
> particularly interested in how you represent the component implementation
> artifact like <implementation.cpp> as I want to understand how we mirror
> the
> reference representation in an extension.
>
> For example, in your restructuring exercise where is ServiceProxy going to
> end up? I would like some core representation of the proxy (reference) so
> that I can either use this natively or mirror it in user space in any
> extension I write.
>
> Anyhow I guess I need to wait to see the details of what you are
> proposing.
> Are you going to be able to talk us through it?
>
> Regards
>
> Simon
>
>


-- 
Pete

Re: [C++] SCA Extensions architecture

[Simon Laws <si...@googlemail.com>]

On 8/17/06, Andrew Borley <aj...@gmail.com> wrote:
>
> Pete,
> Sounds good to me, I'll definately be interested in reviewing if you have
> something to show before tomorrow (Friday) afternoon (I'm on holiday for
> the
> week after that). The Python stuff I've been doing will need fitting in to
> the structure you've put together, so I'd be interested in seeing the
> interfaces you're making for the CPP extension.
> Once that's in place I guess we'll start looking at binding and interface
> extensions, and then there's wiring policies, data bindings, etc, etc to
> look at!
>
> Cheers
> Andy
>
> On 8/17/06, Pete Robbins <ro...@googlemail.com> wrote:
> >
> > I've started playing around with loading extension libraries to support
> > "other language" extensions and so a wee bit of re-architecture has
> "cpp"
> > being an extension language. In other words I'm trying to make a core
> that
> > is not tied to cpp implementation. This core will roughly be a model
> > loader
> > in line with the assembly model spec with extensions for stuff like <
> > implementation.cpp.. > and a runtime for resolving wiring and locating
> > services. This is nearly what we have now but without the cpp C&I spec
> api
> > implmentation code (anything under runtime/core/src/osoa...).
> >
> > This will involve a bit of refactoring to remove the unnecessary
> > dependencies from the "core" to the cpp specific code.
> >
> > What I expect to end up with is libraries for:
> > tuscany_sca - the core assembly model and internal message structure
> > tuscany_sca_cpp - the cpp language extension (extension functions for
> > loading cpp model etc.)
> > tuscany_sca_cpp_osoa - the "client" side functions defined by the C++
> C&I
> > spec (ComponentContext etc.)
> >
> > I'm not yet sure if the latter 2 should be the same library, that will
> > depend on their interdependencies.
> >
> > This is not a trivial change and it's tricky to break it down into
> > sensible
> > small chunks so I may start a branch/sandbox to play in for the
> > moment...or
> > if it suddenly all works I'll get it checked in to the trunk asap ;-)
> >
> > It's nearly there but will probably take another day or maybe 2 and it
> > would
> > probably be good for anyone else interested in the cpp code to review
> it.
> > It
> > won't be near perfect but it will provide a good base for a more modular
> > and
> > extensible runtime.
> >
> > Cheers,
> >
> >
>  Pete



Count me in too.  Very interested in reviewing the new layout. I'm
particularly interested in how you represent the component implementation
artifact like <implementation.cpp> as I want to understand how we mirror the
reference representation in an extension.

For example, in your restructuring exercise where is ServiceProxy going to
end up? I would like some core representation of the proxy (reference) so
that I can either use this natively or mirror it in user space in any
extension I write.

Anyhow I guess I need to wait to see the details of what you are proposing.
Are you going to be able to talk us through it?

Regards

Simon

Re: [C++] SCA Extensions architecture

[Andrew Borley <aj...@gmail.com>]

Pete,
Sounds good to me, I'll definately be interested in reviewing if you have
something to show before tomorrow (Friday) afternoon (I'm on holiday for the
week after that). The Python stuff I've been doing will need fitting in to
the structure you've put together, so I'd be interested in seeing the
interfaces you're making for the CPP extension.
Once that's in place I guess we'll start looking at binding and interface
extensions, and then there's wiring policies, data bindings, etc, etc to
look at!

Cheers
Andy

On 8/17/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> I've started playing around with loading extension libraries to support
> "other language" extensions and so a wee bit of re-architecture has "cpp"
> being an extension language. In other words I'm trying to make a core that
> is not tied to cpp implementation. This core will roughly be a model
> loader
> in line with the assembly model spec with extensions for stuff like <
> implementation.cpp.. > and a runtime for resolving wiring and locating
> services. This is nearly what we have now but without the cpp C&I spec api
> implmentation code (anything under runtime/core/src/osoa...).
>
> This will involve a bit of refactoring to remove the unnecessary
> dependencies from the "core" to the cpp specific code.
>
> What I expect to end up with is libraries for:
> tuscany_sca - the core assembly model and internal message structure
> tuscany_sca_cpp - the cpp language extension (extension functions for
> loading cpp model etc.)
> tuscany_sca_cpp_osoa - the "client" side functions defined by the C++ C&I
> spec (ComponentContext etc.)
>
> I'm not yet sure if the latter 2 should be the same library, that will
> depend on their interdependencies.
>
> This is not a trivial change and it's tricky to break it down into
> sensible
> small chunks so I may start a branch/sandbox to play in for the
> moment...or
> if it suddenly all works I'll get it checked in to the trunk asap ;-)
>
> It's nearly there but will probably take another day or maybe 2 and it
> would
> probably be good for anyone else interested in the cpp code to review it.
> It
> won't be near perfect but it will provide a good base for a more modular
> and
> extensible runtime.
>
> Cheers,
>
>