Hooks in Base Code

[Jim McDonald]

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
may want to do something with it.

The other key thing to realise here is that each of these modules will
be a nice and simple beast that understands its own job and neither
knows nor cares about what is going on elsewhere in the system.  Writing
a piece of code that will carry out the above function is simple, but if
it was to be inserted in to gsmd (or the notification system) then it
would be a much bigger task as you need to understand how the existing
system works, where your code fits, write something, send it in as a
patch, get it reviewed, and finally in the next major release of the
software it will show up.

(Also bear in mind that incoming calls are a very simple example as
there is not much that I can think of doing with them off-hand. 
However, if you start to think about outgoing calls there are many more
things that you may want to do, including allowing/not allowing the call
(for child or business 'phones), routing the call through another system
(calling cards), sending/not sending your caller ID with the call,
allowing/not allowing calls to call anyone not in your address book,
only allowing non-business calls outside of business hours, who knows? 
The point is that every time we build a static code path we're limiting
the ability of the next person to do something we didn't think of, which
makes the whole thing less free than we would like.

I'd again say to look to the Firefox extensions system as a good example
of where this has worked well, and not only gives people lots more
freedom in how they surf the web but has made the browser far more
powerful (and successful) that it could have been with any single set of
developers while at the same time making it easy for outside developers
to add to the product with minimal, if any, knowledge of the existing
codebase.  I think that is the model that openmoko should be trying to
emulate, otherwise we'll just end up with an open source 'phone with all
of the inflexibility of  a closed source 'phone (to the majority of
people that might use it), and that doesn't seem to be a great leap
forward from where things are today.

Cheers,
Jim.