Re: [Accessibility-atspi] D-Bus AT-SPI - The way forward

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

	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.

	HTH,

		Michael.

-- 
 [email protected]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
Gnome-accessibility-devel mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel