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
--- Begin Message ---
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.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
--- End Message ---
_______________________________________________
Gnome-accessibility-devel mailing list
Gnome-accessibility-devel@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
