[Accessibility] Re: [Accessibility-atspi] D-Bus AT-SPI - The way
michael.meeks at novell.com
Mon Dec 10 08:45:52 PST 2007
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
> 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):
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 ;-)
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 ].
Another query - wrt. lifecycle mechanisms: what would be proposed for
lifecycle tracking object peers inside providing applications ?
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.
michael.meeks at novell.com <><, Pseudo Engineer, itinerant idiot
-------------- next part --------------
An embedded message was scrubbed...
From: michael meeks <michael.meeks at novell.com>
Subject: D/BUS thoughts ...
Date: Mon, 09 May 2005 16:53:03 +0100
More information about the Accessibility