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

[David Bolter <david bolter utoronto ca>]

Just a quick (and late) note, that I really appreciated this heads up 
and would very much like as much detail as possible as work progresses.

cheers!

David
GOK project

Bill Haneman wrote:

> 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
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel