I notice in implementing the PHP extension (yes - believe it or not I'm nearly ready to make a patch for the next version ;-) that, given the way that I have implemented the PHP extension there is insufficient information available in the SCA runtime in order to do correct type conversions when passing messages between components. I imagine this has been raised before but I looked at the archive and couldn't find a relevant thread.
Imagine the scenario: C++ Component (ComponentA) ---WireA---> PHP Component (ComponentB) ---WireB----> C++ Component (ComponentC) Currently the build process looks at the header files described in the component type files and generates wrappers and proxies for the C++ components. I have currently implemented the PHP Extension to use generic wrappers and proxies, i.e. it doesn't use those generated based on the interface descriptions, so they need to dynamically manage the type conversions for data coming in and going out of a PHP component. WireA. This is OK because the C++ SCA operation object that appears at Component B has a set of data/types based on the generated proxy. The PHP extension can look at this and effect the right type conversions. WireB This is problematic. The dynamic PHP proxy has to generate an operation object to pass to the the wrapper of ComponentC. The issue is that there is, as far as I can tell, no dynamic way of getting at the list of types that are expected for any particular operation. There is of course a static C++ proxy/wrapper combination that has been generated but I can't inspect it at runtime. I'm not keen on generating PHP specific interface classes. PHP is a dynamic environment and it's a whole stack of extra files we could do without having to manage particularly if we have to adapt the generator for every extension that's constructed. Can we extend the wrapper/proxy mechanism to encapsulate a runtime list of required types alongside the static method descriptions that are already generated? We would need this to work for script to script calls as well as for the script/C++ combination so maybe we need something that hangs off the interface description part of the model. I'm not that familiar with how that part of the model is used so a little investigation is required. Thoughts? Simon
