Hooks in Base Code
thehans at gmail.com
Sat Jul 21 08:07:24 CEST 2007
Great discussion going on here. I've been putting a lot of thought into the issue too, so I figured I'd add my two cents. Originally I tried to imagine how all these events and notifications would go together, and I came up with this wishlist item: http://wiki.openmoko.org/wiki/Wishlist:ANARM . The allow/deny concept is pretty limited in usefulness, but luckily my views have changed a
lot since I first wrote that. I now see this not as a firewall analogy, but more of a routing analogy. I'm not really familiar with iptables, but it sounds like Henry Law's last message is pretty close to what I'm getting at. In trying to architect this complex framework, I think it will help to use some of the fundamentals of unix programming, which go something like this: write programs that "do one thing and do it well", and make it easy for these programs to be combined in useful ways.
So this is a game where the goal is to take events and deliver them to
the proper handlers. This game involves a number of players:
- A single "Profile Manager"
- A single "Event Router"
- Any number of "Event Generators"
- Any number of "Event Handlers"
When broken down in this manner each player is not particularly complex, but as a team, they are able to accomplish the goal.
Let me explain the roles of each player:
The Event Router take incoming events(sent in from Event Generators),
checks it's rulebook, and forwards the events to Event Handlers. Each rule in the rulebook would consist of an event selector, and the event handler to use with that selector. A selector is some sort of expression that all events can be checked against, to see if they are a match, or not. I use the term "selector", since I think it's purpose is comparable to CSS selectors. Any given event might match more than one rule, giving the Event Router the ability to forward to multiple handlers at once.
An Event Generator is any program that is capable of sending a message to the Event Router. Generally each event generator will only generate a single type of event: (incoming calls, incoming SMS, incoming email, etc.) Every event will carry with it some unknown amount of data. So the message it sends to the router should be in some generic data interchange format for ex. XML, or maybe JSON(see http://json.org).
An Event Handler is any program that is capable of receiving a message from the Event Router. An event handler might play a sound, display something on screen, send out an SMS, send data to nearby computer over bluetooth, forward to another event handler (for example "Jeff's 3 rings in 5 minutes urgent call handler" would normally do nothing(stay silent), but could forward to the usual ringer handler under the right circumstances), etc.
The Profile Manager defines which rulebook the Event Router should be using at the moment(did I mention the Event Router has more than one rulebook? ;-D ). The Profile Manager is the one who takes into account things like "GPS location is inside a movie theater", "GPS location is at job" or "It's past bedtime", etc. Profile manager has mechanisms to automatically set the current profile(rulebook), but profiles can also be set manually by the user. Only one profile can be active at a time.
So in the future, when we need to extend the functionality, all that is needed should be either a new Event Handler, or Event Generator, and update the rulebooks. Rulebooks would be stored in text files, but the phone would of course have nice GUI interfaces that could generate the configs for you.
Hope all that made sense(it does in my head anyways :-P)
- Hans Loeblich
On 7/20/07, Jim McDonald <Jim at devzero.net> wrote:
> Giles Jones wrote:
> > I don't think the project will last long if there's too much snobbery
> about who does what.
> In this case it isn't snobbery so much as ensuring that there is a
> simple way to put the right functionality in the right place.
> Overloading gsmd with lots of (potentially conflicting) user
> requirements would lead to code that was hard to maintain and with a
> steep learning curve, hence the point that only those who put the time
> and effort in to understand all of the wrinkles would be able to make
> safe changes, and these people would be 'core' developers purely because
> that's where they would have to do the development to get the
> functionality they required.
> 'core' isn't a synonym for 'better' here, it just refers to developers
> that work on the core functionality of the product rather than the (in
> my opinion) more interesting stuff of the higher-level applications.
> OpenMoko community mailing list
> community at lists.openmoko.org
More information about the community