contexts, profiles, proposition

[Guillaume Chereau]

On Thu, 2008-07-31 at 12:00 +0200, Jürgen Pabel wrote:
> I would like to add one "feature" to the system: notification of
> applications that a profile change has occured.

It already exists in fact.

The signal is called 'Notify', and is emitted by a preferences service
-preference parameters are grouped into "services"- when any
configuration value of this service has been changed. Either by an other
application, either because the current profile changed.

For an application it makes no difference if the value has been modified
by a change of profile or by an other application.

simple python example of a application that is interested by the 'x'
parameter of the service 'A' :
----
self.service = dbus.get_object(preferences.GetService('A'))
self.x = self.service.GetValue('x')

def on_conf_changed(self,name,value):
    # Could have been called because an other app set the value,
    # or because the current profile changed.
    if name == 'x':
       self.x = value

self.service.connect_to_signal('Notify', self.on_conf_changed)
----


-charlie

>  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
> 
> 
> _______________________________________________
> smartphones-standards mailing list
> smartphones-standards at linuxtogo.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.openmoko.org/pipermail/devel/attachments/20080731/c93f8c6d/attachment.pgp