Re: [g-a-devel] Overview of DBus ATSPI design
- From: Li Yuan <Li Yuan Sun COM>
- To: Rob Taylor <rob taylor codethink co uk>
- Cc: gnome-accessibility-devel <gnome-accessibility-devel gnome org>, accessibility-atspi-linux-foundation <accessibility-atspi lists linux-foundation org>, Michael Meeks <michael meeks novell com>
- Subject: Re: [g-a-devel] Overview of DBus ATSPI design
- Date: Tue, 08 Jan 2008 14:04:42 +0800
On 一, 2008-01-07 at 17:14 +0000, Rob Taylor wrote:
> == 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.
Yes, this is what I am thinking about. One question is how do we handle
remote applications that show on the current display?
Li
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]