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

[Bill Haneman <bill haneman sun com>]

On Tue, 2002-07-16 at 22:18, David Bolter wrote:
> 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.

Hi David, 

Sure, glad this was useful.  The work in question was done pretty much
the same day that the email was written.

I am a little puzzled by what you mean by "would like as much detail as
possible" since I don't believe anything in gok can be / has been
impacted by this change.

-Bill

> 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
> >
> 
> 
>