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

[Michael Meeks <michael meeks novell com>]

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.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot

--- Begin Message ---

• From: michael meeks <michael meeks novell com>
• To: Havoc Pennington <hp redhat 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

	+ 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. **

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

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

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

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot

--- End Message ---