Talk:Proposal for context management
From Openmoko
(New page: What do you think about defining "position" as depending on distance to certain GSM towers as well? Is less battery-consuming than turning on GPS and waiting to get a fix, and it gets a ro...) |
m |
||
| Line 1: | Line 1: | ||
What do you think about defining "position" as depending on distance to certain GSM towers as well? Is less battery-consuming than turning on GPS and waiting to get a fix, and it gets a rough distance to the desired point. I.E. while looking for "home" do not attempt to get a GPS fix until the GSM towers you see are the same that you see in "home"; as well you won't need 1m precision always, and when you don't the GSM triangulation could be enough... | What do you think about defining "position" as depending on distance to certain GSM towers as well? Is less battery-consuming than turning on GPS and waiting to get a fix, and it gets a rough distance to the desired point. I.E. while looking for "home" do not attempt to get a GPS fix until the GSM towers you see are the same that you see in "home"; as well you won't need 1m precision always, and when you don't the GSM triangulation could be enough... | ||
| + | |||
| + | |||
| + | ---- | ||
| + | 2008-07-01 jOERG: | ||
| + | I think we need a NOT-operator for the conditions, e.g. "not at position-xy". | ||
| + | |||
| + | Also manually selected profiles, like D.N.I, could have conditions to disable them or more precise reenable auto selection. E.g. when I select "silent mode" for a meeting, it would come in handy to disable this by some gesture like walking, or by changing (GPS-)location. Also I'd probably still like to have my "low power" profile still on guard. | ||
| + | Maybe we need a more complex way to define which transitions are valid in this state-machine, means defining which profiles may follow on a particular profile | ||
| + | |||
| + | Further conditions might come in handy, by simply calling scripts and checking for their returncode. So I might e.g. check the noise of environment and switch to "high volume" profile if in a noisy place. | ||
| + | |||
| + | A timer started by activation of a profile seems nice. | ||
| + | Maybe start a script on activation and on deactivation. | ||
Revision as of 00:23, 1 July 2008
What do you think about defining "position" as depending on distance to certain GSM towers as well? Is less battery-consuming than turning on GPS and waiting to get a fix, and it gets a rough distance to the desired point. I.E. while looking for "home" do not attempt to get a GPS fix until the GSM towers you see are the same that you see in "home"; as well you won't need 1m precision always, and when you don't the GSM triangulation could be enough...
2008-07-01 jOERG: I think we need a NOT-operator for the conditions, e.g. "not at position-xy".
Also manually selected profiles, like D.N.I, could have conditions to disable them or more precise reenable auto selection. E.g. when I select "silent mode" for a meeting, it would come in handy to disable this by some gesture like walking, or by changing (GPS-)location. Also I'd probably still like to have my "low power" profile still on guard. Maybe we need a more complex way to define which transitions are valid in this state-machine, means defining which profiles may follow on a particular profile
Further conditions might come in handy, by simply calling scripts and checking for their returncode. So I might e.g. check the noise of environment and switch to "high volume" profile if in a noisy place.
A timer started by activation of a profile seems nice. Maybe start a script on activation and on deactivation.
