Advice requested on deprecating AT-SPI/CORBA

[Willie Walker <William Walker Sun COM>]

Hi All:

We're slated to have the AT-SPI/D-Bus stuff in place for 2.29.2.  Things 
are chugging away and looking positive.  I have some questions about 
some approaches we are going to take and would like some opinions and 
advice for how to do it better if your stomach is weakened by the 
proposed approaches.  In other words, speak up now before it's too late. ;-)

One of the goals is to try to keep the AT-SPI/CORBA stuff around for a 
bit so as to let people who depend up AT-SPI for other things to have 
some stability.  The current path is that people would get AT-SPI/D-Bus 
with GNOME 2.29.2 by default, but we'd have an option for people to 
choose AT-SPI/CORBA if they want/need it.

For the most part, we can set things up so there is very little overlap 
between AT-SPI/CORBA and AT-SPI/D-Bus on the file system.  The two main 
overlaps that we are facing are the atk-bridge GTK+ module and the 
pyatspi module.  We also need to deal with *not* always launching the 
AT-SPI/CORBA at-spi-registryd deamon when we know the AT-SPI/D-Bus stuff 
will be used -- launching the CORBA and D-Bus based registryd's 
simultaneously can cause the desktop to hang.

Not launching both registryd's at once
--------------------------------------

The AT-SPI/D-Bus registryd starts/restarts via D-Bus activation, so 
there's no need for it to have a *.desktop file and it will only launch 
if someone tickles it (e.g., via the D-Bus based atk-bridge or pyatspi 
module).  The AT-SPI/CORBA registryd, however, currently starts with an 
autostart *.desktop file,
/etc/xdg/autostart/at-spi-registryd.desktop, that is keyed off the GNOME 
a11y gconf key, /desktop/gnome/interface/accessibility.

As a potential solution, we can modify the AT-SPI/CORBA *.desktop file 
to key off of a new gconf key, /desktop/gnome/interface/at-spi-corba. 
The existing /desktop/gnome/interface/accessibility key will be used 
everywhere else as normal, but this new key will be used to specify 
whether the old or new infrastructure should be used.

atk-bridge
-----------

Due to others hardcoding the string "atk-bridge" in their code (e.g., 
Firefox and OOo), the GTK+ a11y module has to be named "atk-bridge".  We 
could ask Firefox and OOo to not hardcode the name, but we'd end up in a 
versioning hell with external apps not tied to the GNOME release 
schedule.  So, I'd like to make the simplifying assumption that they 
will not change and we need to deal with "atk-bridge".

As a possible solution, we can modify AT-SPI/CORBA 2.29.2 to install its 
atk-bridge module somewhere else (e.g., 
/usr/lib/gtk-2.0/modules/at-spi-corba/libatk-bridge.so).  We would then 
modify the AT-SPI/CORBA registryd to modify gnome-session's GTK_PATH to 
find the CORBA-based GTK+ module first.

pyatspi
-------

The "pyatspi" module is used by many Python source modules, such as 
Orca, accerciser, and LDTPv2.  The AT-SPI/D-Bus "pyatspi" module is also 
designed to be a drop in replacement for the AT-SPI/CORBA "pyatspi" 
module.  As a result, a name change would be both unnecessary and 
cumbersome.

As a possible solution, we can modify AT-SPI/CORBA 2.29.2 to install its 
pyatspi module under site-packages/pyatspi-corba/pyatspi and put a 
site-packages/pyatspi-corba.pth file in place.  The pyatspi-corba.pth 
file would prepend Python's sys.path with site-packages/pyatspi-corba if 
a new gconf key, /desktop/gnome/interface/at-spi-corba (the same one 
described above), was True.  This is admittedly a big hack, but the 
thinking is that we really only want this scaffolding in place until we 
finally pull the plug in AT-SPI/CORBA.

Thoughts?

Will