About Context Aware Applications

[Guillaume Chereau]

On Wed, 2008-07-02 at 12:07 +0200, Thomas Seiler wrote:
> 2008/7/2 Guillaume Chereau <charlie at openmoko.org>:
> 
> > The way it works is by having one configuration file *per application,
> > per profile*.
> 
> Just thinking, wow that leads to a lot of config files....
> 
> Woulnd't it make sense to have some sort of implicitness or inheritance in the
> design, so that when you want to change a behavior globally, you woudn't have to
> edit tens of files.
> 
> I.e. having a default.conf and a profile dependent add on that is able
> to override:
> 
> cat default.conf $profile.conf > current_config.conf ?
It is already the case. I didn't mention it not to make things too
complicated. I don't actually do the cat, but the preferences service
will look for the default conf file when it can't find the value in the
profile conf file. 

> 
> must my 0.02 $
> 
> Cheers,
> Thomas
> 

At the beginning I didn't think that we would have too many profiles.
I only though of choosing one profile depending on the context, and then
application configurations depend only on the profile.
So for example, you could say :

- if I am in a noisy environment, or if it is very early the morning :
then I switch to "outdoor profile", then the applications will use the
"outdoor profile" set of configuration values.

To put it in a mathematical way, when an app wants to access a
configuration value, with a given key, the operations are :

current_profile = F(list_of_current_contexts)
shema_file = F(application)
conf_file = F(current_profile, shema_file, key)
value = F(key, conf_file)

Now, as Emanuele said in an other tread, we may also want to have
different configuration parameters directly depending on the contexts,
not via the profile.
For example : If I am near the train station, I want to use a given
dictionary for my keyboard application.

If we want to have that kind of things, then how can we do ? One conf
file per context ? Context information into the profile conf file ?

Or we could even say that we don't provide this kind of abstraction, and
if an application needs to deal with context, it can still use the
context service to know the active context, and then decide what to do
accordingly.

Now why do I chose one file per application per profile ?
I want to have a text format storage. yet, I need to update the storage
from time to time (in the best case, every time a value is set).
If I use a single file for all the conf parameters, it means I need to
write a lot. If I use one file per parameters, then I have to deal with
too many files.
One conf file per application per profile seemed to be a good
compromised, **as long as we don't have too many profiles**

-charlie


-------------- 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.linuxtogo.org/pipermail/smartphones-standards/attachments/20080702/09ed7323/attachment.pgp>