contexts, profiles, proposition

[Michael 'Mickey' Lauer]

Am Donnerstag 31 Juli 2008 10:55:00 schrieb Guillaume Chereau:
> 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".

I like that -- this will put the logic into the daemons (where it belongs) and 
out of the applications.

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

Agreed.

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

Sure thing.

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

Ok, great. Please do that. Also, please add one task:

* Make oeventd use org.freesmartphone.Device.Audio instead of using GStreamer 
directly.

Please use today's teleconference (which unfortunately I'm unable to attend 
due to an important matter) to consult with Jan, who was previously working 
on oeventd.

Additional topics I'd like you to disuss today are:

* accelerometer system load
* unit tests for individual subsystems
* enhancing the documentation

-- 
:M: