[ccmtools-devel] python + independence layer

[Darrell S. <da...@sc...>]

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