[g-a-devel]Providing more data with GNOME_Accessibility_Event: ABI vs API preservation

[Bill Haneman <bill haneman sun com>]

Hi:

This is a question about whether we should consider breaking bincompat
for at-spi 2.2 or add new API and code instead.  In a few weeks we may
have rules about this ;-)  but in the meantime I think it's a valid
question, there are pros and cons to both approaches to solving a
current need (see below).

We have identified a need (and previously mentioned it on this list)
regarding more complete data for our ordinary events (as opposed to
device events).  We can't guarantee state-coherence for real clients,
due to three things:

* for Java apps in the java-access-bridge to at-spi, we must queue our
notifications to avoid deadlock since the ORB is servicing AWT events
across threads (and AWT access needs to always be in the same thread);

* clients often need to queue their incoming at-spi events to avoid
re-entrancy problems of their own;

* putting the events in a queue gives more flexibility and helps keep
apps and at-clients from blocking one another.

But this means that our existing event structure, which usually returns
things like indices and text offsets, is unreliable since the text
offsets and/or indices into a hierarchy may be invalid when the event is
actually serviced.  This is particularly bad for things like text
changes, where text insertions and deletions may need to be reported to
the end user; if the indices have changed in the meantime, for instance
in the case of deletion, a client can only reliably report the change if
it maintains a complete cache of the text contents!

So it would be nice to have a CORBA_any member of our event structure
that could be filled with event-type-specific data, for instance the
string representing the text "delta", or an IOR for a new or deleted
child object, etc.  (Of course to prevent lots of remote unrefs we might
want the IOR in such cases *not* to hold a refcount, so the client would
still need to detect object validity by checking any subsequent query
return values, as it always should).

There are two proposed approaches:

1) add a CORBA_any to the event struct;
2) add new API for notifyEventFull, new callback typedefs, a new signal,
   and change clients over to the new APIs.

The first one breaks bincompat (for our modest number of clients) but
would work with just a recompile.

The second choice preserves API and bin-compat, but would require more
new and partially-redundant code, and require more recoding work of
clients that needed the new API (i.e. all clients ;-).  It would mean
two different kinds of EVENT signals, and two different types of
AccessibleEvent callbacks, and a new constructor for the event listeners
(taking the new callback type as a param).  In short, a lot more churn.

The only code with at-spi dependencies at this time is:

* java-access-bridge
* gok
* at-poke
* gnopernicus

Of these none are in CORE yet.  In either case I plan to privide a patch
to java-access-bridge.  The gnopernicus team stands to benefit the most
from the changes.

Personally I and now favoring a recompile against the bigger event
struct but either seems workable, at some cost.

best regards,

Bill