|
From: Darrell S. <da...@sc...> - 2005-08-10 19:19:31
|
I've been working with CCMTools pretty steadily for the past 3 months, and I've made a number of changes. The RPMs etc of the current state of my changes can be found at ftp://ftp.cv.nrao.edu/ casa/ccmtools/. I'm not sure of the best way to make these available, but in time I hope to get these changes merged into CCMTools. These RPMs were created on a RedHat 9 system. I'm not sure what version of *nix most people on this list use... RH9 is now quite, quite old... Here are the changes I've made: (1) created a native binding of local components to Python (2) added a CCM, CORBA,CCMTools independent layer which extracts out all of the types (e.g. structs) that are absolutely necessary in a form that can be included with an application library to create a standard C++ interface to the component which mirrors the IDL definition as well as the local interface. For our system, this will be where developers implement the "business logic". It differs from the standard *_impl files in that it is completely independent of CCMTools, no includes, dependencies, etc. (3) code to handle default values which are specified in XML. This allows CCMTools to generate the standard C++ defaults for (2) as well as default values for invocation from Python. This is intended to augment the IDL with default information (4) code to handle XML customizations for the mappings (this bit is partially complete). This allows for customization of the generated code for particular types. An example of where this will be used is to map native python complex => IDL "struct complex { double re; double im; }" => standard C++ complex & vice versa... so the interface in (2) will take a "complex", the IDL will show a struct, and the python user will enter Python complex values. (5) code to handle XML customizations to provide for (limited) polymorphism in the generated bindings. This allows the IDL to specify a "sequence<Double>", but the generated code will accept a "Double" and build the std::vector<double>" for use by the local component. This is done on a per IDL type basis. The last thing I have in mind to add is: (6) a way of filling default value from a dynamic runtime system like dbxml. This will allow saved user state to be used to fill parameters which will be used to invoke the local component. It will just be a hook to permit this. If anyone is interested in more information about something in particular or has some suggestions, please send an email. I mostly wanted to give Egon a heads up so that he can consider how/when/if parts of these changes can be merged into the development tree. I think I have about a month's work of work to iron out the remaining issues with these changes... though I'm sure there will be some ongoing work. Darrell |