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



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]