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
