Re: [g-a-devel] Overview of DBus ATSPI design
- From: Rob Taylor <rob taylor codethink co uk>
- To: Li Yuan <Li Yuan Sun COM>
- 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 18:54:58 +0000
Li Yuan wrote:
> 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?
Well, as we've discussed in previous mails, the options for a
user/distro are:
1) use a modified sshd that forwards your session bus along with the
X11 connection [1], or
2) enable TCP connections for the session bus for the display and set
up your DBUS_SESSION_BUS_ADDRESS environment variable to point to that
address/port.
It'd be great to be able to support 1). I've had contract the occasional
volunteer to write such a patch for openssh, but I haven't seen any code
yet. It shouldn't be too hard to write though getting it in openssh
itself may take a while. Distros could always choose to ship with such a
patch.
Thanks,
Rob
[1] http://lists.freedesktop.org/archives/dbus/2007-March/007199.html
> Li
>
--
Rob Taylor, Codethink Ltd. - http://codethink.co.uk
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]