RFC: FSO, filtering signals, and interapplication interfaces
xbmodder+openmoko at gmail.com
Mon Jan 12 00:41:56 CET 2009
When I heard that you wanted to put this into the API consumer, I
cringed slightly. For example, if someone wants to write voicemail
notification handling, they'd have to integrate it into all of the
current FSO consumers available. This could be quite painful. Unless
we implement some sort of standards that FSO consumers have to follow.
Mickey, I agree that we might want to integrate this feature into the
higher level APIs (ophoned). Anyways, this is a fairly critical
feature for anyone who wants to use GSM without causing the dialer to
give notifications to the user.
So, do you have an alternate proposal which we can achieve:
1) "Intercept" signals and process them, to see if they should be suppressed.
2) Block signals from hitting the user (not the dialer, just surpress
it in the UI)
3) Wont require HUGE changes of the API
On Sun, Jan 11, 2009 at 7:00 AM, Michael 'Mickey' Lauer
<mickey at vanille-media.de> wrote:
> First off, thanks for this proposal.
> Unfortunately I'm not sure whether this idea is suitable for FSO. I'm not
> feeling too well when thinking about the possible consequences.
> Assuming your primary use case is a call and SMS firewall, I don't think we
> want that in ogsmd. Ogsmd offers simple procedural access to the gsm low
> level functions and as such its signals should not be filtered or altered in
> any way -- otherwise you change application behaviour for any listeners, such
> as call loggers etc.
> Going one layer above, it might be more suitable for ophoned, which is the
> object-oriented technology-independent voice call service. Then again, I
> think I would rather change its API to an agent-model than filter signals.
> That way you would get roughly the same effect.
> In general though, I question whether these features might be better off
> living in the application layer. Remember that a full fledged telephony
> application will probably not use the oeventsd rules anyways.
> smartphones-standards mailing list
> smartphones-standards at linuxtogo.org
More information about the smartphones-standards