On 8/18/06, Pete Robbins <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > On 8/17/06, Andrew Borley <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
