contexts, profiles, proposition

[Jürgen Pabel]

I would like to add one "feature" to the system: notification of
applications that a profile change has occured. There's an obvious
reason: this would allow for a "push" triggered profile-has-changed
handling (instead of on the 1st pull after the change-of-profile). But
there's also a non-obvious reason: if applications only "pull" single
items from the currently active profile (ring tone, activation of
interfaces, ...) then it inconsistencies will likely occur as there's no
more (read or write) "transaction" guarantee. 

With a notification that another profile was activated, applications can
implement a handler that ensures application-wide profile-"consistency"
by re-querying any profile items that might have interdependencies with
other profile items used by that application.

jp


Am Donnerstag, den 31.07.2008, 16:55 +0800 schrieb Guillaume Chereau:
> Hello all,
> After reading the few use cases on the wiki page[0] I think I come with
> a simple system that would fit each cases.
> 
> 1: the preferences service stays the same, that is : the
> applications/services are unaware of the profiles, but when they get
> configuration values, they will get the value corresponding to the
> current profile. e.g :
> Profiles.GetService('Phone').GetValue('ring-tone') may return 0 if the
> current profile is "Silent" but 10 if the current profile is "Outdoor".
> 
> ALSO : the 'default' profile is used whenever a value is not defined in
> the current profile -I know we could think of a real inheritance of
> profiles, but I am afraid it will make things too complicated for the
> user-
> 
> 2: We extend the events service to deal with rules of type :
> 
>   AT event, IF [AND/OR condition1, AND/OR condition2, ...] THEN TRIGGER
> [action1, action2, ...]
> 
> Example of events : arriving at home, time changed to 10:00, incoming
> call, etc...
> Example of conditions : meeting scheduled at 10:30, current profile is
> "silent", caller is charlie, etc...
> Example of actions : set current profile to "home", notify incoming
> call, notify start alarm, etc..
> 
> (Note that I write 'notify incoming call' and not 'ring', because I
> think the decision of actually starting the ring tone should be left to
> the software)
> 
> All the cases written on the wiki are easily supported by this idea.
> 
> If this scheme is not enough for some specific applications, they can
> still listen to events from the framework and use there own scheme.
> 
> If I don't see any objections, I will start working on this. The task
> will include :
> 
> - Add a conf file with the rules, that will be used by oeventsd (the
> rules are persistent)
> - Modify oeventsd API so that we can dynamically add or remove rules
> - Modify zhone to use the new API
> - Add a user interface to configure the profiles and the rules (this one
> is probably the most difficult)
> 
> - Charlie
> 
> 
> [0]
> http://www.freesmartphone.org/index.php/Talk:Implementations/OpenContextDaemon
> _______________________________________________
> smartphones-standards mailing list
> smartphones-standards at linuxtogo.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards