Re: Proposed implementation agnostic GNOME Speech API

[Bill Haneman <Bill Haneman Sun COM>]

Olaf said:

> [Bill Haneman, Di 16.12. 2003 13:07:13]
>  
>
> > > I already addresses the cross-desktop interoperability issue.  Also,
> > > remember that in the accessibility cases at least, KDE will be
> > > working with (and indirectly depending on) CORBA also, via its
> > > at-spi support layers.
> >    
>
> This description is quite misleading, unfortunately. No KDE accessibility=20
> tool currently uses CORBA, and noone in the KDE project currently plans=20
> to use CORBA.
>  
Sorry if you feel this was misleading;  I however stand by my comments. 
I don't see any plans for KDE-based screen readers, 
focus-tracking/intelligent
magnifiers which rely on application-accessibility data, or other 
KDE-specific assistive
technologies which use the information provided by ATK.

I think this is a _good_ thing, since writing such assistive 
technologies is a very
large effort which would be damaged by excessive fragmentation, at least 
at the
current time.  The nominally 'GNOME' assistive technologies were 
designed _not_ to be
GNOME-specific, as is evident by their interoperation with Mozilla and 
OpenOffice.

As you saw in the Harald Fernengel's recent email, KDE/Qt has already been
bridged (at least in proof-of-concept stage) to ATK and AT-SPI.  In 
order to use at-poke
as shown in the screenshots he sent, the ATK-to-AT-SPI bridge is loaded
dynamically as you mention below; Thus interoperability with the 
existing API-based
FOSS ATs requires AT-SPI communication via a 'bridge' layer.  No matter 
what you do,
ATs of this type will require rather powerful IPC service-based APIs, 
and CORBA has strong
advantages in this respect for cross-platform and network transparency.

> The Qt Accessibility Framework can be briged by Qt to ATK on Unix, MSAA on=
> =20
> Windows and Apple's accessibility framework on MacOS. This way, KDE=20
> applications will be fully accessible via whatever native accessibility=20
> API is used on the host system.
Note that MSAA appears to be going away; it probably won't be available on
MS platforms going forward (i.e. Longhorn).  But I agree that creating 
platform-appropriate
bridges makes a lot of sense.

> If we decided to use the CORBA-based AT-SPI directly for KDE=20
> Accessibility, then we would loose interoperability on the native MacOS=20
> port of KDE.
>
> Please note that the Qt-ATK bridge is a server side bridge only. AT=20
> clients based on KDE would still have to speak CORBA to connect to=20
> AT-SPI. This is the reason why I doubt that any KDE-based AT-SPI clients=20
> will be written. But since doublicating the effort of writing Gnopernicus=20
> or Gok or dasher is not my aim, this is OK for me. There are, however,=20
> some KDE developers for whom having native AT clients is important, and I=20
> have not yet managed to convince them to write a client side bridge from=20
> AT-SPI to a new KDE assistive technology API.
>
> =46or text-to-speech services, using CORBA as IPC is not possible at all fo=
> r=20
> KDE. I plan to add text-to-speech functionailty to the messaging=20
> framework in kdelibs, which means only DCOP or maybe later D-BUS can be=20
> used. Requesting CORBA usage for any application using tts is not an=20
> option in KDE.
>  
There are two considerations here; first use of text-to-speech by 
'assistive technologies', which
will by and large require AT-SPI or a yet-to-be-created KDE equivalent 
(which I still think would
be a shame); and secondly, 'self voicing' applications which do their 
own speech.
Self-voicing can be useful at times, but great care must be taken not to 
conflict with
screenreaders - in many cases better consistency can be achieved by 
doing all speech from
the screenreader.

> While I agree that D-BUS currently is not stable enough, introducing an=20
> implementation independent API now would make it much easier to move to=20
> D-BUS once it has become stable enough.
>
> If you wish to tie speech synthesis to CORBA on GNOME, then this is OK for=
> =20
> me as long as a future transition to an implementation independent=20
> protocol is not completely ruled out for the case that D-BUS is being=20
> adopted by both KDE and GNOMEat a future point.
>  
One reason why we chose CORBA/Bonobo for the implementation layers in 
AT-SPI and
also gnome-speech is that it is really the IDL, not the bits, that are 
normative.  Of course
full binary compatibility requires CORBA, but as long as the 
gnome-speech IDL is used as the
basis, the implementation need not be CORBA.  That is, if a DBUS-based 
transport can be
compiled from (CORBA-like) IDL, the systems can be trivially bridged.

What is desirable is a one-to-one mapping of features and parameters 
between the systems;
these features and parameters are defined by the IDL, which need not 
always be "CORBA IDL"
in the sense that it is fed into a CORBA bindings generator.   My 
recommendation would be that
if the KDE community feels strongly enough about excluding CORBA, the 
logical response would
be to create idl-to-source creation tools from which alternate 
implementations of _all_ the accessibility
IPC could be created, including gnome-speech, gnome-mag, and AT-SPI.  
Then, alternate versions of
the at-spi's "cspi" bindings could be created so that the existing 
at-spi clients could transparently
operate using the non-CORBA IPC mechanisms, without recompilation.

regards

Bill

> Olaf
>
>