Hello. 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 [[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.
THis is interesting but hard stuff. I fear you have to give us some more time for it. 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. :) > 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. regards Stefan Schmidt _______________________________________________ smartphones-standards mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
