Jim McDonald <[EMAIL PROTECTED]> wrote :
> Well yes, that's really what I'm talking about. But there are also > other things that some people may want to do with an incoming 'phone > call that we won't think about. Perhaps send an SMS to another 'phone > to say that a call was received? Just an example, but the point is > that we won't be able to know in advance all of the things that someone > may want to do when a call comes in 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. 4.Notification system returns busy event code to Phone process. 5.Phone process plays busy tone and hangs up. 6.Notification system logs the missed call and does any other configured actions (send SMS, play a sound etc..). I know that there are many possible actions, but each phone component will only have so many possible actions. A phone process will only ever have a few events, pickup, hangup, play tone, hold, conference call etc... When the processes register themselves with the notification system they will send a list of the supported events to it. --- G O Jones _______________________________________________ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
