Re: [orca-list] some programmers want to contribute to orca.

[Peter Korn <Peter Korn Sun COM>]

Hi Halim, gang,

> Hi,
> On Mi, Aug 15, 2007 at 10:53:06 +0200, orca yokoy de wrote:
>   
> > no, it is not a joke.
> > AT-SPI is not used by all access technologies. 
> >     
>
> Which other access technologies you are talking about?
>
>
> Halim


AT-SPI, the Assistive Technology Service Provider Interface, specifies 
the information that is provided by accessible applications to assistive 
technologies (and the questions ATs can ask of apps).  Our 
implementation of AT-SPI uses CORBA for interprocess communication (the 
AT lives in one process, the app another, so we need some form of 
interprocess communication).

CORBA is an object based interprocess communication mechanism (the 
Common Object Request Broker Architecture).  The user interface elements 
in an applications are represented by 'Accessible' objects, these 
objects have methods, and CORBA allows an AT to make remote, 
inter-process method calls on these objects (e.g. to ask an accessible 
for its name, its role, etc.). 

In order to handle all of the potential issues that can arise with 
inter-process communication around objects, CORBA is fairly large and 
complex.  It has to handle the case when the remote object goes away, 
when a method call fails, etc. etc. 

Memory constrained environments - like the OLCP and the Nokia N800 - 
don't include CORBA (whereas many desktop systems like Ubuntu and 
Solaris do).  So, if we are to bring assistive technology support to 
things like the OLCP and Nokia N800, we need to address this situation.

One idea is to see whether we can slim down the CORBA implementation for 
OLCP/N800, on the assumption that AT-SPI may not need everything that 
CORBA provides.  Another idea is to move do a different inter-process 
communication mechanism (and the candidate choice here is D-BUS, which 
has roots in DCOP and the KDE desktop). 

The big, not fully answered question, is whether a D-BUS implementation 
of AT-SPI can do everything we need.  Recent news from Trolltech labs 
(the folks behind Qt, the main GUI toolkit for KDE) sounds promising on 
this front, but I believe a little more investigation and testing is 
needed before we can be sure this will work for us. 

On a related note, I have repeatedly heard the suggestion of "moving to 
IAccessible2" for UNIX.  To quote the character Inigo Montoya from the 
movie The Princess Bride, "I do not think that means what you think it 
means."  IAccessible2 is a port of AT-SPI (or more specifically, the UNO 
Accessibility API in OpenOffice.org) to Windows.  More precisely, it is 
a port of those portions of the UNO Accessibility API which weren't 
already in MSAA (Microsoft Active Accessibility, the fairly simplistic 
and primitive accessibility API Microsoft introduced in 1997).  Thus, 
IAccessible2 is not a complete API, but rather is an extension of MSAA.  
Also, like MSAA, IAccessible2 uses the Microsoft interprocess 
communication mechanism 'COM' (Component Object Model).  COM doesn't 
exist on OLPC or N800.  While I believe there are ports of COM to UNIX, 
nobody I know of is suggesting implementing COM on UNIX an alternative 
to CORBA for accessibility purposes. 

Because toolkits like GTK+ and Qt have been ported to Windows, and 
because IAccessible2 is gaining some traction on the Windows platform 
with JAWS and WindowEyes providing support for it in their screen 
readers, exposing accessibility information for GTK+ and Qt applications 
on Windows via IAccessible2 makes a lot of sense.  Since IAccessible2 is 
derived from the UNO Accessibility API, which itself is expressed in 
AT-SPI on UNIX, having cross platform apps be accessible on both UNIX 
and Windows via what is essentially the same API (though different 
inter-process communication implementation) makes a lot of sense.


To the question Halim asked, about what AT supports a D-BUS 
implementation of AT-SPI, I believe Trolltech labs a fork of Dasher that 
uses it.  As the GNOME Dasher makes fairly simple and limited use of 
AT-SPI, this is a natural first AT to test out.  But as it is nowhere as 
heavy a user of AT-SPI as something like Orca, this port doesn't 
definitely answer questions about whether we can do everything we need 
to in a D-BUS based AT-SPI.  I know there are other, KDE AT tools, but I 
don't think any of them make heavy use of the API either.  All of them 
pre-date Trolltech's work in this area, and I haven't seen any mention 
of them being updated.


Another important facet to this whole discussion is the question of 
whether we actually need to fork/port AT to use the D-BUS 
implementation.  The Accerciser project introduced a Python abstraction 
layer to CORBA AT-SPI.  Moving our Python-based AT (like Orca) to this 
abstraction layer would allow us to substitute something else for CORBA 
(e.g. D-BUS), without needing to fork/port/modify Orca at all.  Orca 
could use CORBA-based AT-SPI on those platforms where that approach made 
sense, and something else (e.g. D-BUS) on others, where that was a 
better choice.  CORBA and AT-SPI have a lot going for them.  They are 
tested and proven technologies.  It may make sense to stay on CORBA for 
a while in the desktop world, even as we move to something else in 
memory constrained environments like OLCP and N800.


I hope this helps clear up a lot of the questions and confusion around 
these topics


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.