D-Bus AT-SPI - The way forward

Hello all,

Available at http
://live.gnome.org/GAP/AtSpiDbusInvestigation is the
results of an investigation into a move of the AT-SPI
interface to a
D-Bus transport. The investigation mainly looks at the
relative
performance of ORBit and D-Bus, but also details some
architectural
issues and a preliminary task list.

In brief:

Performance:

GOK and Orca were profiled to get a good idea of the type of
traffic on
the AT-SPI interface. Using this information the performance
of some of
the most common method calls were tested in D-Bus and
ORBit.

D-Bus is undoubtedly slower at most of the common method
calls, 5-6x
slower when making a call that passes one int as an
argument. When
passing more data per call this speed difference decreases.
ORBit takes
a long time to pass an Object reference, making D-Bus up to
1.5x faster
at these method calls.

Although D-Bus is the slower transport, looking at the calls
made by
Orca and GOK, we feel it will be possible to provide
sensible caching
that should mitigate this effect.

Tasks:

For a switchover to D-Bus a number of core libraries will
need to have
the transport mechanism changed: cspi, pyatspi, GAIL. There
will also
need to be a new Java accessibility back end. Some core
D-Bus work is
also needed, in the areas of interface specification,
bindings and
possibly optimisation.

If you are interested please go and take a look at the wiki
page. We'd
really like to get every ones opinion on what the way
forward for AT-SPI
is in terms of its transport mechanism.

Thanks

Mark

-- 
Mark Doffman, Codethink Ltd. - http://codethink.co.uk

_______________________________________________
kde-accessibility mailing list
kde-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

Hi Michael,

On Mon, 2007-12-10 at 16:45 +0000, Michael Meeks wrote:
> Hi Mark,
> 
> On Wed, 2007-12-05 at 16:56 +0000, Mark Doffman wrote:
> > Available at http
://live.gnome.org/GAP/AtSpiDbusInvestigation is the
> > results of an investigation into a move of the
AT-SPI interface to a
> > D-Bus transport
> 
> 	It's most interesting.
> 
> > D-Bus is undoubtedly slower at most of the common
method calls, 5-6x
> > slower when making a call that passes one int as
an argument. When
> > passing more data per call this speed difference
decreases.
> 
> 	This is simultaneosly pleasing & distressing. That
D-BUS hasn't
> apparently progressed performance-wise to the
(non-optimised) state of
> ORBit2 (effectively in deep-sleep/maintenance mode for
the last 4 years)
> is somewhat surprising. I wonder what is going on
there, must be a silly
> or two in the marshalling logic.
> 
> >  ORBit takes a long time to pass an Object
reference, making D-Bus up
> > to 1.5x faster at these method calls.
> 
> 	I can believe it; CORBA object references are quite
verbose -
> particularly (as you note) when multiple transports are
added: IP / Unix
> etc.
> 
> > Although D-Bus is the slower transport, looking at
the calls made by
> > Orca and GOK, we feel it will be possible to
provide sensible caching
> > that should mitigate this effect.
> 
> 	Quite - ultimately, the choice of transport is moot
IMHO, though
> clearly unifying on a single shared transport layer is
a great direction
> even if, for mindless political reasons, it has to be
"not CORBA".
> 
> > For a switchover to D-Bus a number of core
libraries will need to have
> > the transport mechanism changed: cspi, pyatspi,
GAIL. There will also
> > need to be a new Java accessibility back end. Some
core D-Bus work is
> > also needed, in the areas of interface
specification, bindings and
> > possibly optimisation.
> 
> 	Right; so I guess the sticking point is only Java.
> 
> 	Wrt. core D-BUS work: one of the reasons I was
actually enthusiastic
> about a switch to D-BUS is that it marshals types on
the wire: that
> *should* allow an extremely sexy forward &
backwards compatibility story
> to be developed: that is impossible with CORBA.
Unfortunately, it seems
> that's been mostly ignored despite my attempts to
communicate that:
> generating a shared goal of that for a11y would be
really useful.
> 
> 	What do I mean about compatibility ? cf. the mess
around 'Event'
> 'EventDetails' etc. If we can have a 'struct' that
simply grows as we
> add more fields to it, and gets padded with 0's as
mismatches occur: we
> have an incredibly nice compatibility story. The stock
non-answer to
> this is "ah yes, if you hand-write all your
marshallers / de-marshallers
> - you can get that already !"  which
leads to point b):

Ok, I think I get whats going on here. I imagine this is
more about the
marshaller / de-marshaller code not throwing a wobbly when
there is data
appended to the message that it doesn't expect. Its
certainly something
to think about.

> 
> 	The bindings must be good, and need to be generated
from some sort of
> sane & readable (preferably IDL-like) interface
description. I wrote a
> prototype one in perl long ago, not sure if it's
rescue-able 

I had always imagined that the canonical version of the
AT-SPI API would
rest with the D-Bus XML. Its a difficult one this, XML
certainly isn't
something anyone wants to write interfaces in, but its
currently what
D-Bus introspection uses. Its some extra work to maintain a
version of
the interface, along with the translation tools to an XML
version. 

I guess if there was such a tool already available.. Such as
the
modified version of your perl one , then it
wouldn't be such an
issue. 

> 
> 	Anyhow, the "D/BUS thoughts" I wrote in 2005
is attached, somehow it
> managed not to get moderated when I re-posted it to the
D-BUS list some
> year or so later; perhaps it's only of historical
interest now.
> 
> 	One last concern - was anonymous objects & the
problems of type
> introspection (round-trip-wise). Do we marshal the
interface type of an
> object with it's reference ? [ bit rusty here ].

In ORBit the type gets passed with the object reference.
This prodded us
into a bit of a think on the D-Bus side. You're right, we
don't want to
go introspecting every new object we see just to get the
methods
available on it. I guess this implies some sort of interface
repository
(lets rebuild corba!), along with passing a type signature.


> 
> 	Another query - wrt. lifecycle mechanisms: what would
be proposed for
> lifecycle tracking object peers inside providing
applications ?

No proposals. ATM I'm imagining that all AT-SPI objects die
with their
applications, and not otherwise. If anyone has some examples
of where
this can't be the case we really need to know.

I'm sure we could go the Bonobo route and have a base class
that was
reference counted, but we really don't want to. 

> 
> 	Anyhow - in general, IMHO etc. moving to D-BUS is a
positive move, and
> [ I guess ], the mercy (I hope) is that it can be done
without excessive
> disription to the Python or cspi bindings, and no pain
for atk either. I
> guess as Novell spins up it's a11y team here, we -may-
be able to help
> out with some of the work / testing - though that's
unclear as yet. I'd
> love to follow the design & impl. of the work
myself anyhow.
> 
> 	HTH,
> 
> 		Michael.
> 
> email message attachment, "Attached message -
D/BUS thoughts ..."
> > -------- Forwarded Message --------
> > From: michael meeks <michael.meeksnovell.com>
> > Reply-To: michael.meeksnovell.com
> > To: Havoc Pennington <hpredhat.com>
> > Subject: D/BUS thoughts ...
> > Date: Mon, 09 May 2005 16:53:03 +0100
> > 
> > Hi Havoc,
> > 
> > 	So - at LWE I said I'd scribble down a few notes
wrt. things I
> > was hoping would get done in D/BUS; most pleased
to see the recursive
> > type support. Please do forward to the list if you
think any of it is
> > useful.
> > 
> > 	So - this is informed by the work on ORBit2; we
learned a
> > number of interesting things there over the course
of a few years.
> > hopefully some of these are by now fixed in D/BUS
etc.
> > 
> > * Some lessons:
> > 	+ don't create new type systems
> > 		+ people hate to convert between
representations
> > 		+ people hated (the type-safe, powerful etc.)
CORBA
> > 		  type system; because they had to convert
between
> > 		  GArray & CORBA_sequence_Foo

D-Bus Glib and D-Bus Python marshal directly into the native
type
system. Its a good idea.

> > 
> > 	+ use a recursive type system
> > 		+ all programming languages have them, for good
> > 		  reason.
> > 		+ they allow a nice, simple mapping to many
> > 		  languages.
> > 
> > 	+ a corrolory of that is:
> > 		+ don't proliferate representations
> > 			+ you will always need a native
> > 		 	  representation of XYZ information
> > 			+ if you structure that representation to
> > 			  conform to your type system - you avoid
> > 			  creating 'yet another representation'
> > 		+ ie. it's not a strength to represent type data
in
> > 		  IDL, and XML, and 1-per-language native
parsed
> > 		  forms. Far better to use a common
representation
> > 		  based on the type system.
> > 		+ IPC shouldn't be _that_ difficult, or require
> > 		  _that_ much code
> > 		+ reducing redundant representations helps to
> > 		  substantially reduce code complexity &
ease
> > 		  maintenance.
> > 
> > 	Anyhow - here were some of my thoughts of several
months ago
> > when I last looked at D/BUS:
> > 
> >     * Extensibility
> > 	+ One thing I really like about D/BUS that CORBA
was
> > 	  missing is the extensibility allowed by the
marshalling
> > 	  of type information on the wire. ie. a D/BUS
call
> > 	  would look (in CORBA) like:
> > 		callMethod( in string name, in
sequence<Any> args)
> > 	+ Unfortunately, CORBA relied on a very strong
contract
> > 	  between client & server. There is no need
to do this
> > 	  with D/BUS:
> > 	** extra arguments to functions, extra members in
structures
> > 	   etc. should be silently elided / padded to 0
**
> > 	+ Of course there was interface versioning, and
perhaps that
> > 	  is/was necessary but it never worked well.
> > 
> >     * Anonymous object references
> > 	+ In may applications there are no particularly
obvious,
> > 	  or sensibly unique string names associated with
objects
> > 	  we want to expose.
> > 	** There needs to be a good, performant, standard
mangling
> > 	   for such objects. **

Object references still haven't been sorted. An object
reference is
going to be the bus path, along with an object path unique
to the
application. As mentioned before, possibly a type signature
is needed
also.

> > 
> >     * Introspection - performance
> > 	+ CORBA passes a type-id with every object
reference.
> > 	  While that looks like wasteful overhead, it
allows a
> > 	  remote client to realise that it is of an
identical
> > 	  type to a previously introspected object -
meaning
> > 	  that scripting bindings don't have to do 1
extra,
> > 	  synchronous round-trip per method call, plus a
load
> > 	  of (XML?) parsing to be able to invoke a method
on
> > 	  the object.
> > 	** D/BUS should do something similar, round-trips
are
> > 	   expensive. **
> > 
> >     * Introspection - complexity
> > 	+ As previously discussed; there is a huge
benefit to
> > 	  the existing 'getIntrospectionData' type
method,
> > 	  however - the introduction of a new XML
representation
> > 	  seems unnecessary.
> > 		+ that is particularly true if the base types
> > 		  can be compatibly extended during
marshalling.
> > 	+ this would avoid the need for an XML parser
with
> > 	  commensurate time & space penalty, still
provide
> > 	  equal extensibility, and reduce the
representation
> > 	  count.
> > 	** D/BUS should use it's native type system to
describe
> > 	   types instead of a foreign one **

Damn straight. I really like this. Anyone for
getNativeIntrospectionData()?

> > 
> >     * Mapping recursive types to the native C ABI
> > 	+ This is a simple task - and we should be doing
it to
> > 	  the GArray types - again, not a new idea.
> > 	+ Writing that code is _suprisingly_ complex,
error
> > 	  prone, and difficult to test across the N
architectures.
> > 	+ Re-licensing the ORBit2 code to do it should be
no
> > 	  issue, it's mostly Novell/RH code.
> > 	+ ie. you should be able to call:
> > 		sequence<GdkRectangle> getAreas(in long
index);
> > 	  as: GArray *getAreas(glong index);
> > 	  and get not a GArray of GValue's or some ugly
/
> > 	  cumbersome 'Any' type, but real struct
GdkRectangles.

All about the glib bindings, which do need some
improvement.

> > 
> >     * Flow control & blocking
> > 	+ It is often the case that two processes exist
one
> > 	  producing events & one consuming them.
> > 	+ this situation requires careful handling to
avoid
> > 	  the source out-producing the sink, leading to
run-away
> > 	  memory consumption / failure.
> > 	+ this can either be performed by tiresome,
complex &
> > 	  fragile user-land flow-control; or by the
simple
> > 	  mechanism of blocking the socket to let the
kernel
> > 	  deal with the issue.
> > 	+ unfortunately - most IPC channels are shared;
if an
> > 	  out of control asynchronous event flow blocks
a
> > 	  socket, then no - necessarily-under-control
> > 	  synchronous IPC can get down the same channel
=>
> > 	  deadlock potential.
> > 	+ Thus it'd be nice to have the concept of a
blockable
> > 	  event 'flow', vs. a point-to-point, reliable
IPC
> > 	  channel.
> > 	+ A simple example is the flow of accessible
events,
> > 	  each event often causing the sink to emit
multiple
> > 	  round-trip calls to the source to fetch more
> > 	  information.
> > 
> > 	I hope that helps, sorry it took so long.
> > 
> > 	Regards,
> > 
> > 		Michael.


It was really good to get some more feedback,

Mark

_______________________________________________
kde-accessibility mailing list
kde-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

Hi Rob,

	Thanks for your great feedback, to expand on this:

On Tue, 2007-12-11 at 14:09 +0000, Rob Taylor wrote:
> >>> 	+ A simple example is the flow of
accessible events,
> >>> 	  each event often causing the sink to
emit multiple
> >>> 	  round-trip calls to the source to fetch
more
> >>> 	  information.
> 
> Urk, flow control is hard. The problem with the
solution you propose is
> it forces an application to have a thread for
processing events, and
> then you still end up with a possible starvation
situation when handing
> off events to a mainloop.

	Well, right - if you install another broker you need more
flow control:
in this case to the main-loop. Of course, if you handle this
on the
mainloop, then you don't have that problem  and can
just ignore the
events.
	
> As its stands I've yet to see a real-world usecase for
pumping signals
> faster than user input, though of course, we've tested
this case ;). In
> AT-SPI the event reception is dwarfed by synchronous
calls to handle an
> event, usually to the process that sent the event, so
starvation isn't
> an issue here.

	Well, it used to happen quite easily with key-events; just
turn the
auto-repeat rate up, and hold down a key: now of course,
it's easy
enough to make the AT do enough work on each event to bog
the system
down, and get a produce/consumer rate problem.

	Of course - we 'solved' this problem in at-spi by going
synchronous for
all events; but ...  that's
not such a wonderful solution either.

> IIRC, libdbus at the moment currently always reads data
off the socket
> into a queue of messages to be handled, it'd probably
be good to have a
> method for applications to set a maximum queue size so
they can use a
> direct connection and have the kernel manage their flow
control. This
> should really be a design decision for an application
writer, I don't
> think we can solve it for them in a decent way - and
its not common.

	Sure; it's a matter of just having a separate queue I
guess, though of
course you have to be able to stop polling on the incoming
socket
as/when the queue is full etc.

	HTH,

		Michael.

-- 
 michael.meeksnovell.com  <><, Pseudo Engineer,
itinerant idiot


_______________________________________________
kde-accessibility mailing list
kde-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

Hi Mark,

On Tue, 2007-12-11 at 11:46 +0000, Mark Doffman wrote:
> > 	What do I mean about compatibility ? cf. the mess
around 'Event'
> > 'EventDetails' etc. If we can have a 'struct' that
simply grows as we
> > add more fields to it, and gets padded with 0's as
mismatches occur: we
> > have an incredibly nice compatibility story. The
stock non-answer to
> > this is "ah yes, if you hand-write all your
marshallers / de-marshallers
> > - you can get that already !"  which
leads to point b):
> 
> Ok, I think I get whats going on here. I imagine this
is more about the
> marshaller / de-marshaller code not throwing a wobbly
when there is data
> appended to the message that it doesn't expect. Its
certainly something
> to think about.

	Right; also, not just appended - but appended to eg. a
structure that
is argument 3 of 5 could get extended too, or a structure
that is a
member of a structure (hopefully all handled in a clean
& generic way).

> I guess if there was such a tool already available..
Such as the
> modified version of your perl one , then it
wouldn't be such an
> issue. 

	Heh - that perl is ancient, but perhaps workable in some
form.

> In ORBit the type gets passed with the object
reference. This prodded us
> into a bit of a think on the D-Bus side. You're right,
we don't want to
> go introspecting every new object we see just to get
the methods
> available on it. I guess this implies some sort of
interface repository
> (lets rebuild corba!), along with passing a type
signature. 

	So 
of course, the flip side of not having a fixed type scheme
means
we can (I guess) pass a bit-field (or
human-readable-char-field) with
each reference saying what interfaces it supports - to
reduce
synchronous query-interface traffic (?).

> > 	Another query - wrt. lifecycle mechanisms: what
would be proposed for
> > lifecycle tracking object peers inside providing
applications ?
> 
> No proposals. ATM I'm imagining that all AT-SPI objects
die with their
> applications, and not otherwise. If anyone has some
examples of where
> this can't be the case we really need to know.

	Quite - there are lots of examples. Basically we need to
keep state in
the application for atk peers - they are created, and
(AFAIR) they are
needed to keep around for various things.

	That would be fine, since we have a nice strong lifecycle
mechanism -
the window's visibility 
unfortunately at this point Documents
arrive:

	*Unfortunately* - various creative types decided that what
the world
really needs is to expose the entire DOM, though the main
use for this
is for the blind. Thus, instead of exposing just the visible
area [ plus
some nice 'page-down / next-heading' style navigation
interface ], we
expose a potentially infinite space  The
problem with that is that we
-have- to have explicit lifecycle management (of some form)
[ or use
custom references & transient objects of some form -
which is hard on
atk. ].

	So the punch line is - (IMHO etc.) we have an unfortunate
interface
that demands explicit lifecycle, that creates extra
round-trips,
cross-process reference leaks, and various other nightmares
 And
-
get this: the main use-case (AFIACS) is for braille displays
which often
have 2x lines of <N> character text: ie. way less than
is visible (or
could easily be made visible).

> I'm sure we could go the Bonobo route and have a base
class that was
> reference counted, but we really don't want to. 

	Quite - me neither  OTOH,
it's a hard issue to fix: and
precedent-wise, MSAA, IAcc2, UIA, UNO a11y and atk use
reference
counting 

> > > 	** D/BUS should use it's native type system
to describe
> > > 	   types instead of a foreign one **
> 
> Damn straight. I really like this. Anyone for
> getNativeIntrospectionData()?

	 glad
you like it - of course requires the extensibility thing to
be
as 'good' as XML.

	All the best,

		Michael.

-- 
 michael.meeksnovell.com  <><, Pseudo Engineer,
itinerant idiot


_______________________________________________
kde-accessibility mailing list
kde-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

I'm just adding my 2 cents from what I've been finding as a
AT-SPI
nube using pyatspi for Jambu. I started off not thinking
much about
interprocess issues and sort of just assumed the event
handler was
async and I could do what I like in it. I got a rude
awakening when
changes I made affected behaviour in subtle or random ways,
plus I was
getting almost continuous desktop lockups (and forget using
a
debugger).

> > As its stands I've yet to see a real-world usecase
for pumping signals
> > faster than user input, though of course, we've
tested this case ;). In
> > AT-SPI the event reception is dwarfed by
synchronous calls to handle an
> > event, usually to the process that sent the event,
so starvation isn't
> > an issue here.

Populating the file open dialog in gedit in a large
directory
generates plenty of event traffic.

Also I find for simple actions that several of the events
you could
expect to occur for completeness are just not there. If this
is
addressed it may well result in increased event traffic for
simple
application state changes.

>         Of course - we 'solved' this problem in at-spi
by going synchronous for
> all events; but ...  that's
not such a wonderful solution either.

Indeed. For example if you want to print events to see
what's going on
you need to put in a queue to handle it asynch. I've
actually now
decoupled most processing this way at the risk of occasional
timing
issues due to the latency . At least we can assume
reads/writes will
not be pre-empted (I hope). So the onus is on the AT writer
to sort it
out.

-- 
Steve Lee
--
Jambu - Alternative Access to Computers
www.fullmeasure.co.uk
_______________________________________________
kde-accessibility mailing list
kde-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

Hi Steve,

On Fri, 2007-12-14 at 18:23 +0000, Steve Lee wrote:
> plus I was getting almost continuous desktop lockups
(and forget
> using a debugger).

	Heh  sure,
from my at-poke days I recall a load of methods that
simply couldn't be called during event emission for various
tangled
reasons (in the gail implementations).

> Indeed. For example if you want to print events to see
what's going on
> you need to put in a queue to handle it asynch. I've
actually now
> decoupled most processing this way at the risk of
occasional timing
> issues due to the latency

	Right - and this is the irony of synchronous event
delivery: that at
some stage, people do this for ~everything anyway . Of
course - the
problem is - switching to a fully async event model (as we
had
initially) ends up with horrible produce/consumer rate
mis-matches:
hence the desire for a 'flow' concept 

	Having said that, it'd be great to build an understanding
of what
people do synchronously during event emission & can't do
elsewhere: to
add to the events themselves.

	HTH,

		Michael.

-- 
 michael.meeksnovell.com  <><, Pseudo Engineer,
itinerant idiot


_______________________________________________
kde-accessibility mailing list
kde-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

Michael Meeks wrote:
> Hi Steve,
> 
> On Fri, 2007-12-14 at 18:23 +0000, Steve Lee wrote:
>> plus I was getting almost continuous desktop
lockups (and forget
>> using a debugger).
> 
> 	Heh  sure,
from my at-poke days I recall a load of methods that
> simply couldn't be called during event emission for
various tangled
> reasons (in the gail implementations).
> 
>> Indeed. For example if you want to print events to
see what's going on
>> you need to put in a queue to handle it asynch.
I've actually now
>> decoupled most processing this way at the risk of
occasional timing
>> issues due to the latency
> 
> 	Right - and this is the irony of synchronous event
delivery: that at
> some stage, people do this for ~everything anyway . Of
course - the
> problem is - switching to a fully async event model (as
we had
> initially) ends up with horrible produce/consumer rate
mis-matches:
> hence the desire for a 'flow' concept 

Righty, I think I know how it'd be possible to have flow
control on a
dbus direct connection (custom GSource, message queue
limit), but
there's obviously a cost to having a direct connection from
each
application to each AT. Though we'd only need to use this
direct
connection for sending events so the main cost here
(assuming most
people don't run more than 4 AT's) is about 4*cost of
sending message
per event (which we kinda have right now with registryd).

Another option is rather than having real flow-control, we
could just
mitigate the problem by having an event signal be an array
of events and
specifying (say) that event signals should be sent no faster
than one
per 1/10 or 2/10 of a second, with some session-wide
synchronisation of
the timeouts a-la g_timeout_add_seconds. Of course it would
still be
possible to have a producer-consumer rate mismatch, but the
control
would be in the hands of the AT, which would know it always
has about
1/10 of a second to service an event signal.


What do you reckon?

> 	Having said that, it'd be great to build an
understanding of what
> people do synchronously during event emission &
can't do elsewhere: to
> add to the events themselves.

Yes! Please let us know, AT coders of the world!

Thanks,
Rob

> 	HTH,
> 
> 		Michael.
> 


-- 
Rob Taylor, Codethink Ltd. -  http://codethink.co.uk
_______________________________________________
kde-accessibility mailing list
kde-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

Hi All:

I still need to catch up on all this mail.  It's all good
stuff, and I'm 
excited to see intelligent and cooperative conversation
going on.  In 
the meantime...

>> 	Having said that, it'd be great to build an
understanding of what
>> people do synchronously during event emission &
can't do elsewhere: to
>> add to the events themselves.
> 
> Yes! Please let us know, AT coders of the world!

I think there are a couple things to consider: 1) is there a
need for an 
AT to process events synchronously, and 2) what other
information can be 
sent in an event to avoid extra round tripping?

For the first question, Orca pretty much queue's all events
and 
processes them on the gidle thread.  There are a few
exceptions, but I'm 
not sure they require synchronous handling.

When it gets an event, a lot of what Orca does is:

o Determine which application the event came from.  This is
important 
because Orca allows scripting per application.  Luckily,
most toolkits 
support putting the application in the event, so we're
pretty good with 
that.

o Look at the role of the event source.  Passing this along
in the event 
would prevent a round trip.

o If Orca decides it needs to present something about the
event source, 
we also typically look at the ancestry of the event source. 
The main 
reason for this is to compare the ancestry of the current
object with 
focus to the ancestry of the object that previously had
focus so that 
Orca can present contextual changes in location.  I'm not
sure sending a 
complete ancestry with every event would be desirable,
though.

o The profiling work at 
http://live.gnome.org/GAP/AtSpiDbusInvestigat
ion/OrcaExtraProfiling can 
also be used to give more insight.

Having said that, the main area where handling events
synchronously is 
desired is with testing.  With this, we have a better chance
at 
repeatable test results since the application's state will
essentially 
block until we process the event in a synchronous manner.  A
notable 
example of where asynchronous event handling can yield
different results 
is typing in text areas.

Will
_______________________________________________
kde-accessibility mailing list
kde-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

On 17/12/2007, Willie Walker <William.Walkersun.com> wrote:
> o Look at the role of the event source.  Passing this
along in the event
> would prevent a round trip.

Doesn't the EventDetails expansion cover this? It appears to
be
optional if the toolkit supplies but potentially the
infrastructure
could fill it in.

http://www.gnome.org/~billh/
at-spi-idl/html/structAccessibility_1_1EventDetails.html


> o If Orca decides it needs to present something about
the event source,
> we also typically look at the ancestry of the event
source.  The main
> reason for this is to compare the ancestry of the
current object with
> focus to the ancestry of the object that previously had
focus so that
> Orca can present contextual changes in location.  I'm
not sure sending a
> complete ancestry with every event would be desirable,
though.

This must be a common requirement as you need to know if a
change
furthet up the tree possibly effects your 'state'

-- 
Steve Lee
--
Jambu - Alternative Access to Computers
www.fullmeasure.co.uk
_______________________________________________
kde-accessibility mailing list
kde-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility