[g-a-devel]HEADS-UP: at-spi event refcount change

[Bill Haneman <bill haneman sun com>]

Hi:

In dealing with a number of bugs filed against AT-SPI and also
ORBit2/linc, the decision has been made to make at-spi's event listener
"notifyEvent" call drop the "oneway" directive.

This is because the use of oneways is inherently problematic when large
numbers of calls are being made by an ORB client, and in servicing those
calls, synchronous callbacks from the server result.  The problem
appears to be quite intractable from an ORB/CORBA point of view, without
introducing new, nonstandard API in the ORB itself.  Some client-side
workarounds suggest themselves, for instance relying on a async
'handshake' periodically from client to server, to ensure that the
server-side ORB is not being overloaded.  However the additional problem
of ORB event reordering in oneway calls would remain, and even those
solutions would require POA policy changes from the ORB and could not be
guaranteed to work across various ORBs.  

The change has the following effects:

(1) application latency can be increased since the atk-bridge's event
calls are now synchronous.  This will eventually be remedied by the use
of an event queue in the atk-bridge itself.

(2) event reordering no longer occurs as a result of ORB reentrancy in
servicing notifyEvent calls; this is a win since numerous bugs have been
filed against the event reordering.

(3) since event notification is synchronous, we no longer have to rely
on the remote server to unref() the event source once the notifyEvent
call has been serviced; this reduces the number of synchronous calls
required greatly, and has allowed the elimination of many ref()/unref()
pairs.

It does, however, mean that listeners are no longer expected to unref()
the sources of the events they receive.  For AT clients using the CSPI
bindings there is no apparent effect since the unref() was handled
previously by the CSPI bindings, but any AT clients which used the CORBA
bindings directly should remove the unref() call at the end of their
notifyEvent server-side implementation.  The only affect on users of the
CSPI bindings is this: if CSPI clients wish to use direct pointer
comparison to test the identity of two Accessible object instances, they
must ensure than an explicit reference to both objects is held by the AT
client, e.g. the AT client must have called "ref()" on the accessibles
before comparing them.  Alternatively, a client can call
cspi_object_equals () rather than using the pointer comparison 
("a == b").

The only clients known to be affected at this time are the java
accessibility bridge sample clients, but I felt it was important to
inform the whole GNOME Accessibility development community of this
change in policy.  As I said, no impact on existing AT vendor code is
anticipated as a result of this change.

The changes discussed here are in CVS HEAD, at-spi version 1.1.0, and
will be bundled with GNOME 2.0.1 and later.  GNOME 2.0.0 will ship with
the previous implementation, and be based on at-spi-1.0.X.

thanks and best regards,

Bill