Re: [g-a-devel] [Accessibility-atspi] AT-SPI and D-Bus

[Willie Walker <William Walker Sun COM>]

Hi Olaf:

> I am getting the impression that the GNOME accessibility developers do not 
> care about making it easier to implement interoperability with Qt and KDE, 
> and would instead like push a libbonobo-based AT-SPI version into the LSB and 
> make people believe that all full-featured assistive technologies are GNOME 
> tools anyway.

As the lead for the Orca project, I can tell you that my primary agenda
is making the desktop and its apps a productive and compelling
environment for users.  The AT-SPI happens to be the solution we are
using because it helps us meet this agenda.  

The client/server model to accessibility is something I've been working
on since the early 90's when I worked on RAP (the Remote Access Protocol
for the X Window System), which I also helped carry forward into the
Java Accessibility API when I joined Sun in early '97.  No solution is
perfect, and we learn as we go.

IMO, the AT-SPI model works and we should continue to work with it and
with each other to improve it.  Incompatible and competing
infrastructure solutions for the same platform seem more detrimental
than helpful to me.  If there were any disruption to happen in this
space, I think I'd rather see the entire industry rally behind a common
model that works across all platforms and operating systems.  Who knows,
maybe a web-services approach with well-defined interfaces might be
neutral ground.   But...that's future work.

More specific to the discussion at hand...  ;-)

Under the covers, Orca's main view of the world is via the IDL
interfaces for AT-SPI, gnome-speech, and gnome-mag.  We view these IDL
interface definitions as primary specifications for the assistive
technology's side of the world.  A big benefit of using IDL is
programming language independence: you write your server in whatever
programming language you want, I write my client in whatever programming
language I want, and we both communicate using the IDL as our normative
language.  In addition, environments such as Python have features (e.g.,
PyBonobo and PyORBit) that will dynamically provide Python bindings
directly from IDL, thus eliminating the need for anyone to hand craft
client-side bindings.

The communication with IDL-based services is done via the Python support
for bonobo/ORBit/CORBA.  As such, there are some bonobo/ORBit/CORBA
dependencies in Orca's source code, but we've pretty much limited these
specific bonobo/ORBit/CORBA references to the small set of modules
needed to manage the setup and tear down of the communication.

The remainder of the code in Orca that talks to the outside world is
primarily concerned with the IDL.  As such, my hope and recommendation
is that any non-bonobo/ORBit/CORBA solution taken on by KDE would
continue to support the IDL model.  

>From other e-mail, I see that Gary Cramblitt is looking at what it would
mean to add support in Orca to allow it to talk with both the
CORBA-based IDL solution and the KDE DBUS-based IDL solution for AT-SPI.
I'm not sure we've heard from Gary directly, but we're happy to discuss
ideas with him!

Will