Jim McDonald wrote:
Giles Jones wrote:
Jim McDonald <[EMAIL PROTECTED]> wrote :
This is why you send the event to the notification system and then wait for the response. The notification system would read the users rules and act appropriately.
For an incoming call if you had a rule which says you are busy then the process
would be as such:
1.Phone process receives incoming call event.
2.Phone process sends call details and incoming call event to notification
system.
3.Notification system checks user settings.
Agree up until now, but this is the bit where we diverge; I believe that
if done properly there could be any number of responses to the fact that
there is an incoming call, and they won't all fit happily in to a
simplistic event code model.
Let's pick a simple example mentioned earlier on the list, where the
'phone is set to reject all calls but if someone calls three times in
five minutes then you want to make the 'phone ring because it may be
urgent. Now, the really important bit here is not the technical details
of how it accomplishes the requirement but the fact that it is highly
questionable if you want to put this type of functionality within your
base 'phone. It being just one of no doubt 100 esoteric features that
end users will come up with you don't want to be faced with a massive
set of options or a slow 'phone because it's checking so many things
every time someone calls you. You want this to be a much more flexible
system, and to do that you need to think of the 'notification' system as
a central messaging hub where it can pass on the fact that there is an
incoming call, along with the details of that call, to any module that
The diversity seems base on assumption that notification system
will broadcast the event and allow multiple response from different
modules.
What about using a system similar to iptables? Each module only
provide function to "match" against some call info. Some "target actions"
are defined by the notification system. And rules is setup by user
so that when a call event come in, the notification system can
check the call info against the rules one by one until one is match and
do the "target action" in that rule. Normally each "target action" will
do their jobs and then terminate the matching process.
For more complex situation, "target action" may allow continue
of the matching process (e.g. call history logging or send out sms),
but this own exist when both the module is allow and user have
add addition option on that "target action".
This should cover all condition which can be represent by AND/OR logic
and is easy to implement. The only drawback is the rule setup interface
may not be friendly enough for normal user.
Regards,
Henry
_______________________________________________
OpenMoko community mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/community
