[omniORB] omniORBpy users please read

[Duncan Grisby]

If you have read the draft Python CORBA mapping, you will know that it
disagrees with itself about whether the skeleton package for module M
should be called POA_M or M__POA. I submitted an issue to the OMG
about this, and I chose POA_M as the mapping in omniORBpy. This seemed
like the most sensible choice since the majority of other language
mappings use POA_M; none use M__POA. Everyone in the Python CORBA
community seemed happy with this choice.

Unfortunately, last month the Python mapping finalization task force
decided to use the M__POA mapping. This means that omniORBpy is now in
conflict with the standard. Since this affects all server code written
for omniORBpy, I would like to ask for some input from users.

We have several options on how to proceed:

1. Try to get the standard mapping changed to POA_M. One way of doing
   this is to convince the relevant OMG people that it is an "urgent
   issue", to which they have to respond within 14 days. This will
   only be possible if a significant number of users assert that it
   will cause serious difficulty for them to change their code.

2. Change omniORBpy to use the new mapping, breaking all existing
   server code. This is the easiest way for omniORBpy to support the
   new spec. I have no feel for how difficult users would find it to
   modify their code, or how much code there is out there.

3. Change omniORBpy so omniidl generates code for both mappings, for
   ever more. Unfortunately, this isn't entirely trivial to do, due to
   the way the mapping works. This option will bloat both omniidl and
   the generated code. It will also provide little incentive for
   people to change their code to the new mapping.

4. Convert to the new mapping, but support the old one as a switch to
   omniidl. This bloats omniidl even more, but only bloats the
   generated code if the old mapping is in use.

5. Go with option 3 or 4, but remove support for the old mapping after
   some period of time.

I would appreciate it if you could let me know what you are doing with
omniORBpy, and which of these options you think would be best (or any
other ideas you have). Unless you think your comments should be
discussed on the list, please send them just to me, to avoid
cluttering the list.

Thanks,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --