What do you guys think?
Title: FSO, filtering signals, and interapplication interfaces
Version: 0
Last-Modified: 2008-01-06
Author: Sargun Dhillon [[email protected]]
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.
Background:
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.
Proposal:
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
functions.
This will keep going until the last callback has been executed, then
it'll broadcast it to the intended receivers.
Alternatives:
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.
_______________________________________________
smartphones-standards mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
