[omniORB] IDL stub topology in python

[Thomas Lockhart]

>> I get these same files and one additional file b_idl.py at the top 
>> level. The other files are modified to import both a_idl.py and 
>> b_idl.py (pretty slick side-effect behavior from omniidl). 
> Yes this side-effect behaviour is a pain which precludes the use of 
> omniidl with parallel make :-(

Hmm. I hadn't thought of that. Add it to the list of goals for 
improvements...

>> 1) Why is a_idl.py (and b_idl.py) imported from all levels of the tree? 
> The file "a_idl.py" has that name because it was generated from "a.idl", 
> not because it contains a definition of "interface a".

Thanks for the clarification.

> "a_idl.py" contains the appropriate python translation of everything in 
> "a.idl".  The other directories and python files that you mention only 
> exist so that the python "import" statement works properly...
> ...  Do you see now the reason for the generated subdirectories?

Sure. I'm not questioning the existance of the subdirectories (I rather 
like them :) but am wondering about how much actually needs to appear 
*above* these subdirectories for each interface or package, since they 
can and do result in file name collisions and ugly packaging issues.

>> 2) Why are a_idl.py and b_idl.py not isolated down into the 
>> appropriate subdirectories to avoid file name conflicts with other 
>> modules? Would it not be possible to import x.y.a_idl (and x.y.b_idl) 
>> and reduce the possibility of conflicts with, say,
>>   module m { module n { interface a {}; }; }; 
> This example would not produce a conflicting *_idl.py filename unless 
> you have two *.idl files with the same filename.

OK, then I'll change the example :)

The collisions can happen if I have an interface defined for one project 
with the file name the same as the interface name (a reasonable 
possibility) and I want to replace that with a new interface and new 
file for another project with the same name but different definitions 
for methods (say, to change the data type of one parameter in the call 
list).

There is the potential for file name collisions depending on the names 
of the original source files, *and* these files appear above and outside 
of the target namespace directory for the stub and skeleton products.

So if I have a shared code tree that defines an interface for "widget 
A", and then a project that needs to redefine that interface for their 
own "widget A", and if I want to package each set of code into their own 
  "namespaces", say "shared" and "specific", then I could install them 
into two directories:

   /usr/lib/python2.2/site-package/shared
   /usr/lib/python2.2/site-package/specific

But filename conflicts could prevent that from happening since there may 
be two "widgetA_idl.py" files at the same level of the installation tree.

Now, one could make it a reasonable policy that *no* idl files are ever 
named the same, but as we get more projects working independently, and 
as we get some code moving back into the shared code, then the 
possibility for collisions increases. Especially if the only fundamental 
reason why it can't possibly work is because of python IDL mapping 
constraints.

What I'd like to be able to do is to use some combination of IDL 
compile-time switches to

1) isolate all code for a (python) namespace into the directories 
associated with that namespace. Seems that "-Wbpackage=" might be able 
to do that.

2) call out to other namespaces from within that code. afaict, 
"-Wbpackage=" puts the same namespace on all included or inherited 
interfaces, so I can't share IDL code between packages in this way. For 
example, if I have project "a", file "one", module "m", and interface 
"x", and I want to inherit that interface in project "b", file "two", 
module "n", and interface "y", I can't do it if I've used "-Wbpackage=a" 
and "-Wbpackage=b" to build project "a" and project "b", respectively. 
Because all references to interface "x" are prefixed by "b", not by "a" 
in the generated python code.

It may be that I'm just not seeing the right combination of current 
features to make this happen (quite likely, but I have been trying 
various combinations and not getting it right). Or it may be that I'm 
not seeing what I *should* be doing with my existing interfaces to 
eliminate these issues, beyond renaming them and then just coping with 
the remaining global packaging problems. Suggestions?

                   - Tom