On 18/08/06, Simon Laws <[EMAIL PROTECTED]> 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
