Filtering special messages. Zhone or FSO?

[Sargun Dhillon]

Filtering:

One way to deal with this [filtering] is by doing function
registration. It would work something like this:
1) Develop would register their function with FSO, with something like
this registerStagedProcessor(signal, myFunctionName, index, timeout)
signal: Which signal you want process
myFunctionName: The name of the callback function
index: The order of which your function is called with the call
object, it would range from [1024, 65535], we could make a wiki page
with known indexes.
[1, 1024] are reserved by "System" functions.
timeout: How long your function is allowed to run without giving some
sort of message back


you would get one of three responses back:
timeout too large, failure
index tied, failure (means someone has already claimed that index)
success!: This means that your function will be called, and given the
path to the call in the order given by the index.

2) When you get an event
You advertise an event, but supply it on a bus called "preprocessed
signals" That way if something needs to act it, it can, it must
realize that the signal is "incomplete." Call the appropriate
functions, in the appropriate order, and on each stage, send out a
"Preprocessed signal"


3) When your function would be called:
You would get path to the phone call (dbus crap), and be allowed to
run for a timeout at least. You should be able to add and manipulate
its attributes (not sure how), and return a few possible things:
Pass, success [pass it blindly to the next stage]
Block, success [try to block this function from hitting anything else,
put a special attribute on it saying "Blocked"
filtered, success [Skip certain indices provided]
altered, success [It has changed the signal, and now FSO knows to
change the signal in the future]

What do you guys think?




On Thu, Dec 11, 2008 at 11:30 PM, Joel Newkirk <freerunner at newkirk.us> wrote:
> On Thu, 11 Dec 2008 21:41:23 -0800, "Sargun Dhillon"
> <xbmodder+openmoko at gmail.com> wrote:
>> So we really need a filtering extension for FSO. It would be really
>> nice if this sat on the FSO level rather than the dialer level. For
>> example, some carriers send out SMS messages with special caller IDs
>> in order to notify customers of voicemail. Instead of this hitting the
>> user and them seeing a rather odd looking message, we could capture it
>> using a "pluggable" app, that would send a newVoicemail signal.
>>
>> I can think of other things like phone call filtering depending on who
>> is calling you, or where you are. I understand this would be difficult
>> to integrate into FSO, as it really isn't the realm of FSO (Blocking
>> call handlers, and call state setting). Especially if you get into the
>> area of setting notification attributes, like "If this call is from
>> _someone unimportant_, and I'm in meeting mode right now, don't ring,
>> or buzz, but if it is from a contact in list "special" then feel free
>> to buzz.
>>
>> This seems like a prime area for the dialer, except if someone writes
>> a simple application for Zhone, there is no way it's porting to the
>> other hundred distributions (not that many...yet). Would it be better
>> to have an entire plugin API to FSO, where dialers can integrate and
>> bring up a settings tab, etc.. I agree that there may be far too much
>> abstraction here, but I'm brainstorming out loud on the best way to
>> write portable applications, with a unified view (UI).
>>
>> What do you guys think?
>
> I think this definitely belongs within frameworkd rather than the dialer -
> you're talking initially about SMS, which would surely not be the realm of
> the dialer, per se.  I've been thinking this same thing, in the context of
> sending various 'administrative' SMS messages to the FR to elicit various
> responses or actions.  (like 'where are you' or 'lock all my data and set
> up a VPN via GPRS to this IP:')
>
> Best to intercept such messages before they reach the 'conscious' level - a
> simple rule for frameworkd could suffice to divert such messages to a
> handler that could authenticate and act on on them (and delete them from
> SIM), instead of alerting and popping up the message onscreen.
>
> It should already be possible with frameworkd to set up CID-specific
> behaviors.  It's not something exposed at the user level but you should at
> least be able to change ringtone/profile or reject a call based on
> callerID.
>
> j
>
> --
> Joel Newkirk
> http://jthinks.com      (blog)
> http://newkirk.us/om (FR stuff)
>
>