Talk:Proposal for context management

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(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 22:23, 30 June 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.

Personal tools

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.