RFC: FSO, filtering signals, and interapplication interfaces
stefan at openmoko.org
Sun Jan 11 02:37:47 CET 2009
On Tue, 2009-01-06 at 19:25, Sargun Dhillon wrote:
> What do you guys think?
> Title: FSO, filtering signals, and interapplication interfaces
> Version: 0
> Last-Modified: 2008-01-06
> Author: Sargun Dhillon [xbmodder+openmoko at gmail.com]
> Summary: This standard proposes a way for FSO, and its consumers to
> interact with one another. The primary area of this particular
> proposal is to decorate signals emitted by FSO. Decoration means
> intercepting signals in a way, and then manipulating them in a variety
> of ways.
> Currently, FSO uses dbus, which emits a multicast signal to anyone
> who is subscribed. These signals include new phone calls, phone call
> changes, and new SMS messages. Normally, the consumer would do an
> action on this trigger. The issue is that FSO wasn't built around the
> idea of multiple consumers. If one consumer's action conflicts with
> another, FSO doesn't have a way to prevent them from interfering.
THis is interesting but hard stuff. I fear you have to give us some more time
On the first reading I got the feeling that it will get a lot more complicated
if we go this way. Something we would like to avoid. On the other hand I have no
simpler proposal to solve it off hand. :)
> The proposal being put forth provides methodology to filter, and
> decorate signals. When an application needs to decorate a signal, it
> would register the decoration function with FSO, and set and index.
> Registration Message ? (SignalName (bus name (s), interface name (s),
> signal name (s)), Index (integer), CallBack (bus name (s), interface
> name, function, Arguments (bin))
> If the index is already registered with this particular, the FSO will
> raise an exception, the FSO does not reorder registered callbacks.
> Also, the index must be between a positive number [1,32767]. In the
> future, there will be an official document to assign indices.
> When a signal is fired, each registered function will be called with
> the arguments (bus name (s), interface name (s), signal name (s),
> Index (I), Argument (bin), SignalData (s)), where argument is what was
> specified when the callback was registered.
> The expected return value will be (Status (I), (Signaldata)). Where
> Status will be 0, if the signal performed correctly. 1 if the signal
> should be dropped. Other values can be added in order to provide other
> This will keep going until the last callback has been executed, then
> it'll broadcast it to the intended receivers.
> There are a variety of approaches to this, including introducing a
> "global lock" to FSO. The concept of a "global lock" would be blocking
> all FSO consumers once one consumer takes control of the control of a
> daemon. The downsides to this is that it could cause a fight between
> different daemons, and result in different types of race conditions.
> Additionally, the integration of a global lock, which also avoids
> "deadlocking" would be overly complicated, and would more than likely
> result in errors on behalf of the FSO team.
More information about the smartphones-standards