[Gpephone-devel] Examining inter-process communication (1) --signal

[YU Yijun RD-ILAB-PEK]

Hi, Florian, 

Thanks for the clarification on DBus. We will start to test and document it and define relevant signals

Regards
Yu Yijun

>-----Original Message-----
>From: Florian Boor [mailto:florian.boor at kernelconcepts.de]
>Sent: 2007年3月28日 0:01
>To: YU Yijun RD-ILAB-PEK
>Cc: gpephone-devel at linuxtogo.org
>Subject: Re: [Gpephone-devel] Examining inter-process communication (1)
>--signal
>
>Hi,
>
>YU Yijun RD-ILAB-PEK schrieb:
>> DBus provides similar mechanism named signal to deal with this type of
>> inter-process communication. However, when a signal is emitted, only
>> those running processes can receive and handle it (right?).
>
>You can do this with DBus as well, that's what the service files are used for.
>These map DBus services to executables.
>
>> I am thinking introducing this inter-process communication to the GPE
>> Phone Edition. In the current implementation, one process can also
>> notify other processes that something has happened, however, currently
>> there is no notification register/un-register mechanism and the
>> notification sender hard-codes to which processes it will notify. e.g.,
>> the phone server can only notify the dialer application an incoming
>> call. If any other applications want also to be notified an incoming
>> call, the phone server source code has to be modified.
>
>I do not see it like this. With DBus you can have multiple scenarios in which
>e.g. a client can just listen on some bus interface and wait for an event to
>occur or a direct communication between objects using a proxy.
>The status applets are examples for DBus clients that do not register their
>namespace and therefore allow multiple applications listening on the same
>signal. So if the phoneserver sends the signal level status message multiple
>applications can listen to it. This should even be possible if one of the
>applications registers this namespace which might be something the voicecall
>application might want to do.
>
>> After implementing the notification/signal mechanism, then we need to
>> define a set of signals on the platform.
>
>What we definitely should do is to have a place where we document the whole IPC
>stuff and which signals are available from which application.
>
>Greetings
>
>Florian
>
>--
>The dream of yesterday                  Florian Boor
>is the hope of today                    Tel: +49 271-771091-15
>and the reality of tomorrow.            Fax: +49 271-771091-19
>[Robert Hutchings Goddard, 1904]        florian.boor at kernelconcepts.de
>
>1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76