[Accessibility] AT-SPI IDL and LSB [was Re: Fwd: X11 libraries requested for future LSB spec]

[Bill Haneman]

On Fri, 2006-06-23 at 09:52, Michael Meeks wrote:
> On Thu, 2006-06-22 at 00:31 -0400, Jonathan Blandford wrote:
> > By 'CORBA details', I meant the detail of using CORBA at all.  The A11Y
> > framework is one of the last users of CORBA on the desktop, and there
> > has been interest in moving AT-SPI to a more maintainable technology
> > like D-Bus in the past.  
> 
> 	I share your concern wrt. standardising on a API that is also the IPC
> interface.

Yes; but this is one of the motivations behind what has come to be
referred to as the "many worlds" proposal (within the FSG discussions). 
More about that below...

> 	OTOH - the bindings are rather nice. I wonder: wrt. ORCA ( and IBM's
> python thing ) - whether we couldn't create a couple of python libraries
> that abstracted away the more 'bonoboy/CORBA-y' pieces here by wrapping
> them - and yet expose the same CORBA / python objects, with exactly the
> same interfaces as at present (derived from the IDL).

If there's a clean way to do that, without producing something fragile
or requiring a lot of manual intervention to maintain, I think it makes
sense.

> 	That'd also have the nice effect of de-coupling the at-spi-registryd
> activation piece from libbonobo, and allowing that to be re-worked
> [ using the new per-display hint ? in future ]. 

I totally agree we should avoid including the activation bit into the
FSG standard for the time being, to keep bonobo-activation out of the
picture.

> Also allowing us to
> change the implementation rather easily later [ although IMHO d-bus is
> prolly still not mature enough for this yet ].

Yes and yes.  (For one thing, Frank Duignan at Dublin Institute of
Technology has done benchmarking in which DBUS was three times slower
than ORBit2, and we don't have a DBUS-IDL compiler or even a clearly
stated mapping from IDL to DBUS.  But for the moment we'll put that into
the 'futures' box).

> 	Of course - wrt. Python API/ABI issues are mostly a matter of the
> meaning of strings :-) and as long as we hide all of those 'CORBA' /
> 'Bonobo' strings that make some foam at the mouth ;-) they need never
> know - and it can be fixed later.
> 
> 	ie. I tend to agree that standardising cspi / a tiny python-spi wrapper
> is (perhaps) a good way to go.

Perhaps, but as you note, cspi was pretty much an expedient that was
hacked up on the spot, and as such it's not a terribly attractive thing
to base one's standardization/interoperability efforts on.  Furthermore,
if one ignores IPC entirely and just specifies the client bindings,
interoperability is far from assured (for instance, in a heterogeneous
KDE+Gnome or KDE+OpenOffice/Firefox desktop where there might be two
different 'cspi' implementations!).  

> 	Clearly though - jrb - in terms of actually producing a real standard,
> having an existing well accepted standard (OMG IDL) to define the
> interfaces in is extraordinarily attractive, vs. the fairly hacked up
> cspi interface.

Yes - and in theory at least, IDL provides us with a totally agnostic
interface.  That's why I've suggested that it be 'normative', but of
course in order to validate against it, one must choose at least one
actual implementation ABI.

> 	Then again - the way things are going, perhaps an IDL derived
> python-only API definition would be adequate for most AT vendors.

While I agree that we shouldn't lock in a wire protocol or IPC
technology, we need some way of providing interoperability at least in
theory, which arguably means that the out-of-process ABI needs to be
based on one of a small subset of known, and hopefully stable,
technologies.  

This is where the 'many worlds' proposal comes in - the idea was to
standardize on a features and API-based specification, but explicitly
state that any validation test suite and corresponding ABI be
non-exclusive; we would need a straightforward process for getting ABIs
added to the list of conforming technologies.  The first conforming ABI
would be the one generated by applying OMG CORBA rules/protocol to the
IDL, but when a DBUS ABI is available (preferably generated by a DBUS
IDL compiler, but potentially hand-crafted according to a consistent set
of mapping rules), that DBUS ABI could also be submitted for acceptance
as a conforming technology.  

Of course in order to guarantee interoperability during a the period of
heterogeneity[*], bridges and/or adaptors might be needed, but at least
with a finite number of conforming technologies and a shared normative
API, such bridges should be both maintainable and reasonably performant.

This not only gives us a migration path, it gives us a way to address
the interoperability issues.  Since AT-SPI (and the overall
ATK/QAccessible/Registry/AT-SPI vertical stack), unlike most LSB ABIs,
crosses process boundaries, it relies on cooperation between consumers
and providers of the ABI in order to be useful, and the mere presence of
a functioning library doesn't ensure that the corresponding service will
talk to the relevant desktop applications.  Thus we need, eventually, to
standardize on the application (i.e. service provider) side as well as
on the consumer side.  ATK is now part of the LSB draft spec, but as it
is unattractive to KDE application developers, it can't serve as a
universal service-side ABI.  Standardizing on a small number of
interoperable (read "trivially bridgeable") IPC ABIs allows us to take
care of the provider side as well as the consumer side of the AT
interfaces.

regards

Bill


* One hopes and expects that eventually a given LSB platform, and all
the applications bundled on it, would migrate to a shared backend, such
as the DBUS one

> 	HTH,
> 
> 		Michael.
> 
> -- 
>  michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot
> 
> 
> _______________________________________________
> Accessibility mailing list
> Accessibility at lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/accessibility