Hey folks,
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 <[EMAIL PROTECTED]> 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.
Cheers,
Jim.
_______________________________________________
OpenMoko community mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/community
_______________________________________________
OpenMoko community mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/community
