Talk:Proposal for context management

From Openmoko

Revision as of 23:47, 8 July 2008 by Jisakiel (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.


2008-07-09 Jisakiel: I was thinking, in particular, as some sort of "artificial intelligence" daemon running in background to detect patterns in the profile switching and suggesting the user (as in "it seems that you use to put your phone in silent mode while around here, do you want me to create a location and associate it to the profile?", or "you are in location /market/. You have a note associated to this set of locations: "buy milk", or a less useful "you are near ThisGuy's house, do you want me to call him for both of you to get drunk right now?"). It could be something lightweight and easy to program (set of rules, perhaps fuzzy). Right now I doubt of its feasability because of battery life issues (getting a gps or gsm position means waking up the phone) and API not done, but I'll possibly work on it as my final university project. I haven't started thinking on detail on what it would mean in terms of API though.

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-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.


2008-07-09 Jisakiel: I was thinking, in particular, as some sort of "artificial intelligence" daemon running in background to detect patterns in the profile switching and suggesting the user (as in "it seems that you use to put your phone in silent mode while around here, do you want me to create a location and associate it to the profile?", or "you are in location /market/. You have a note associated to this set of locations: "buy milk", or a less useful "you are near ThisGuy's house, do you want me to call him for both of you to get drunk right now?"). It could be something lightweight and easy to program (set of rules, perhaps fuzzy). Right now I doubt of its feasability because of battery life issues (getting a gps or gsm position means waking up the phone) and API not done, but I'll possibly work on it as my final university project. I haven't started thinking on detail on what it would mean in terms of API though.