Hooks in Base Code

Jim McDonald wrote:
> Giles Jones wrote:
>> Jim McDonald <Jim at devzero.net> 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