Talk:Proposal for context management
From Openmoko
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-05 Kombipom: I think that position information will be provided by the new framework middleware using Geoclue (or something based on Geoclue). This way position can be derived from many sources including GPS GSM and wireless access points.
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.
2008-07-05 Kombipom: I think that being able to start scripts which themselves contain conditional operations would be great. That way the non-technical user can have a simple GUI interface with simple conditions and a more advanced user can add or create scripts to perform more complex tasks. I could see a whole library of scripts appearing on-line.
