Novell's position wrt. Linux / a11y

(Or Michael's unofficial take on what our position should be

could I be bothered to formalize it)

Why I might have something interesting to say & how I am biased:

co-author / maintainer of ORBit2

co-author / maintainer of libbonobo

substantial contributor to at-spi*

creator of the famous: 'at-poke' ;-)

have hacked on D/BUS

currently hacking on a11y unrelated OpenOffice.org issues.

D/BUS vs. CORBA

D/BUS

Pros

a 'politically correct' solution wrt. Qt/KDE.

asynchronous message processing mechanism makes some re-enterancy hazards/deadlock issues less problematic.

Since little is implemented – has a 'perfect' theoretical design.

Cons

horrifically unfinished & immature

has remained in this state for the last ~year without substantial progress.

no IDL compiler

all [de-]marshaling is verbose & has to be hand-written, with error-prone code per-marshaled argument exception handling

no explicit recursive type support

eg. no structures, beyond those you hand marshal element by element.

no functioning introspection

plans for some XML scheme – very under-developed/specified/thought-through

no developed point-to-point capability

all IPC goes via the bus daemon – with commensurate performance loss

Nothing about D/BUS is standardized – and most/much of it remains unfinished & tentative

no stable ABI / API guarantees yet

no on-the-wire protocol guarantees

poor deployment etc.

ORBit2/JavaORB etc.

Cons

potential re-enterancy hazards

can be avoided by some trivial additions to at-spi (support added in the ORB a while back, but not yet used there).

not perceived as KDE-friendly

this based mostly on prejudice and performance issues.

Prejudice perhaps fixable with education

Performance – a non-issue; eg. startup performance with C++ is often re-location processing bound – and C code (ORBit2/glib) is extremely relocation light vs. equivalent C++ code.

Pros

small, fast, cut-down implementation in ORBit2

python bindings via introspection; compiled Java & C++ bindings etc.

Widely deployed & working

remote capable

OMG standardized, understood & interoperable

eg. the C binding is itself specified & standardized in detail.

Summary: to use D/BUS instead of CORBA as the basis would involve:

substantial investment in accelerating the implementation of D/BUS itself.

a complete re-write of the CORBA pieces of at-spi

D/BUS language-binding work / porting to new binding:

Java binding creation

python binding creation

Since there exists working KDE D/COP RPC, it should be possible to bridge this accessibility logic inside the (GPL) at-spi daemon with negligible performance loss for event emission, and some relatively minor performance loss for AT interaction.

One line summary: switching to D/BUS as the native transport is an expensive folly.

The Atk ABI

Overall, I'm quite pleased with this level. While some are keen to 'standardize' this API/ABI – it has to be noted that the atk interfaces require some extensive use of GObject & it's interface support. Perhaps not a simple ABI to codify, or indeed support indefinitely. The one piece to bin is the unfinished DOM interface – IMHO this doesn't make sense to expose at all.

The CORBA Interfaces

There are to my mind several problems with the existing CORBA interfaces – besides a general lack of cleanliness, documentation & due to a few curious choices: extensibility (at least AFAIR from some months ago). However – against this, there is an obvious benefit in a small / referential spec. at this level that avoids some of the intractable in-process glib/ABI problems.

Over-exposure – the big sticking point:

Wrt. the API design my Number One beef here is a design decision that underlies many of the problems – that I still cannot understand the reasons for.

While – by exposing huge swathes of obscured widgets via the accessible APIs makes it potentially possible to write more-optimal display clients without touching the application code [eg. exposing all the mails in a mail folder, when the view only shows ~15 or so], and this seems a nice feature – it has a very large cost. I shall use the E-mail example here for clarity, though this applies to spreadsheets, documents, web-pages, and any conceptually large data set:

Life-cycle – in order to manage the life-cycle of the accessible peers of eg 10,000 messages in a folder – instead of using the existing, excellent life-cycle heuristic of: what is instantiated/rendered – one has to use a reference count. Distributed reference counted is extremely problematic – and is likely to fail, worse it introduces synchronous 'ref'/'unref' round-trip delays from the AT in order to manage the remote accessible reference in the application to be retained.

Round-tripping – excessive round-trips cause acute pain – since there is a potentially large set of child accessibles at any node in the tree – we have a painful iteration process necessarily riddled with round-trips (& hence delays & race conditions): 'long getChildren(); getChild(1); getChild(2); getChild(3);' - ideally we could have a “sequence<Accessible> getChildren()” method – which would perform much faster. We also have extra IPC to unreference child accessibles, (cf. above life-cycle problems) – all of this gives a very substantial performance hit.

A counter-argument is that these children interfaces are in fact not used: if not, one wonders why they exist – indeed, it seems reasonable to have some effective mechanism for determining accessible proximity eg.

Un-bounded sets – at some stage, even the 232 children allowed by this enumerating interface becomes inadequate – eg. in a calender view – it is neither feasible nor desirable to represent all of time in 15minute slots as accessibles.

In summary then – it is vital as a matter of policy to only expose a sensible, and well bounded sub-set of widgets; of course – a notable counter-example would be providing accessibles for available menu items/actions since – while not necessarily visible these represent an immediately usable highly bounded, useful set. Life cycle would be managed by the existing, robust widget life-cycle mechanisms – with the reliable local ORB handle reference counts providing persistent & reliable access to live & defunct remote accessibles.

Improving the CORBA interfaces ...

There are several things that can be done here – in addition to removing the enumeration support above. Primarily – for each structure that is marshaled we should have the ability to append a sequence of name/Any pairs – to allow for more state to be synchronized later in an extensible way. This is particularly important for the basic event structure.

CSPI

A native C wrapper around the CORBA / C bindings – possibly useful because it returns defined return values on exception; and that it hides some of the life-cycle complexity. Removing the life-cycle issues and updating ORBit2 to return defined (null) values even on exception could remove much of this code.

It's also unclear that it's pleasant / a good idea to write ATs in C anyway; python, Java etc. providing a more flexible & powerful base. Ergo – deprecating cspi & formalizing the IDL interfaces more makes better long-term sense I think.

What needs doing:

OpenOffice/Java/a11y

The OO.o/Java a11y bridge to my mind introduces acute problems of blame assignment, quite aside from the lack of a Free Software implementation and the obvious performance problems of the TCP socket transport.

Novell has resources assigned to solving this problem with an in-process direct bridge to the ATK interfaces – that work is due to start soon.

Activation

The activation situation should be tied to X for a few reasons:

to tie a11y more explicitly to a given display/screen-set

to avoid the necessity of use of bonobo-activation

to allow remote X clients to interact with the system.

to make explicit the AT & daemon life-cycle issues

This should in itself be rather trivial – the session manager [ or desktop manager ] just needs to start the at-spi-daemon for that display; whence it can register an Inter-operable Orb Reference [ a plain string ], as a defined X root window property.

ORBit2/X-tunnel based transport

While using the X root window will solve the problem of remote X clients nicely – we would need to enable remote IPv4 networking to make this a reality. This raises some security concerns, for which we can either beef up the SSL transport in ORBit2 – or, tunnel over the X protocol. I had believed that MAS achieved the latter in a borrowable form – however, (AFAICS) it has a crude hack to parse host-names out of DISPLAY and SSL_ environment variables, which is disappointing. Awaiting advice from Keith Packard here.

2005-01-24T12:27:17