Re: [g-a-devel] [Accessibility-atspi] Overview of DBus ATSPI design

[Janina Sajka <janina a11y org>]

We were to spend some time on this week's Open A11y call to learn about
Novell's new initiative, however Calvin cannot make the call this week.

So, perhaps we can devote the bulk of the hour to discussing Rob's proposal below.

Janina


Rob Taylor writes:
> First off, I'd like to wish everyone a happy new year!
> 
> In preparation for the accessibility conf call tomorrow, here's an
> overview of how we currently see DBus-ATSPI coming together:
> 
> == Quick DBus overview ==
> 
> DBus is really very different to CORBA. DBus is a message passing system
> with a defined wire protocol. It is commonly used with a central bus
> daemon that routes messages to protocol and allows discovery.
> 
> There are no defined language mappings, how a message appears is
> language binding and possibly application dependant.
> 
> In D-Bus all messages are passed asynchronously but there is the concept
> of a 'signal' which is a message that does not expect a reply.
> 
> == API and IPC separation ==
> 
> In current AT-SPI the IPC is effectively defined in terms of a
> programmatic API. As we've seen in our profiling of current AT-SPI
> usage, this results in very heavy IPC usage (for what is really not a
> huge amount of actual data).
> 
> We propose that the design of the IPC mechanism should be focussed on
> efficiency and simplicity, and API design should be implemented on top
> of the IPC (per language and possibly per toolkit). Note that at the
> moment almost everyone uses a wrapper around the generated ORBit
> bindings already. One option is to have a common gobject based library
> for use by ATs that can be bound into python or java.
> 
> By having this separation, we can have caching logic below the API and
> optimise for minimal context switches.
> 
> Standardisation of API would be per language and per toolkit.
> 
> My feeling is that it's probably not possible to make everyone use a
> common gobject based library to talk to the wire protocol, hence the
> protocol should be well-described to allow alternative implementations
> and should be forward-compatible.
> 
> == Process Architecture ==
> 
> (see attached png)
> 
> In the current system, all IPC is direct between processes, and there is
> the registry daemon that deals with passing events and monitoring X
> events and sending DeviceEventListener events.
> 
> The D-Bus session bus already acts as a central process for passing
> messages and signals. In this respect it is well suited to acting as a
> replacement for the registry daemon. The D-Bus session bus also has
> advanced filtering mechanisms for deciding what signals a process wishes
> to receive. Messages can be filtered by object path, interface, and even
> message body. This could allow AT-SPI clients to register to receive
> certain events from particular applications, and cut down on IPC traffic.
> 
> A process will still be required to monitor and forward device events to
> the message bus. The D-Bus bus daemon could be modified to perform this
> task, but it is just as easy to use a separate process. The use of a
> separate process will mean the D-Bus session bus can be used. This is
> already present in all distributions using D-Bus, making acceptance easier.
> 
> == Events and Signals ==
> 
> AT-SPI uses the EventListener and DeviceEventListener interfaces to
> notify AT processes of application and device events. As events are
> passed as method calls, they are delivered synchronously. Despite this
> AT processes all seem to queue the messages to process later,
> effectively making event notification asynchronous.
> 
> We propose that events should be asynchronous at the IPC level, using
> the DBus 'signal' message type and routing.
> 
> In an asynchronous message passing system there is always the
> possibility of a producer-consumer rate mismatch. Given that most AT's
> have already subverted the existing synchronous event system to be
> asynchronous in order to avoid deadlocks and other issues, it seems that
> asynchronous message passing will be fine, and such mismat In a
> producer-consumer rate mismatch case with DBus signals, the signal
> messages will either queue in the bus daemon or in the receiving process.
> 
> == Reference Counting ==
> 
> We propose that there should be no implicit cross-process reference
> counting in the IPC design.
> 
> The interesting case where reference counting is useful is when reading
> large documents. Ideas are appreciated for how to approach this. One
> possibility maybe a separate 'interface' in the IPC mechanism for
> navigating within large documents which may be only partially laid-out.
> 
> Thanks,
> Rob
> 
> -- 
> Rob Taylor, Codethink Ltd. -  http://codethink.co.uk


> _______________________________________________
> Accessibility-atspi mailing list
> Accessibility-atspi lists linux-foundation org
> https://lists.linux-foundation.org/mailman/listinfo/accessibility-atspi


-- 

Janina Sajka,	Phone:	+1.202.595.7777;	sip:janina a11y org
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina a11y org	
Linux Foundation		http://a11y.org