About Context Aware Applications

[Guillaume Chereau]

Hello Emanuele.
First, let me explain the current idea behind the profile system :

Right now I am focusing on a preferences service that is aware of the
profile. That is, applications don't need to care about the current
profile, they just access configuration values, and the preferences
service will return the value corresponding to the current profile. 

The way it works is by having one configuration file *per application,
per profile*.
For example if you have an application dialer, and an application
message, and 2 profiles : default and silent. You will have 4
configuration files :
conf/dialer/default.conf, conf/dialer/silent.conf,
conf/message/default.conf, conf/dialer/silent.conf

So the preferences service needs a way to know the current profile (for
the moment it is just a value you can set) and will chose which file to
use depending on it (you can also specify that a parameter don't depend
on profile, and then it is always taken from the default conf file)

== How it can be extended to your context idea : ==

Instead using a single profile value, the preferences service could use
a list of activated context (and then the profiles would just be special
cases of contexts)
Then we store one conf file per context e.g :
conf/dialer/default.conf, conf/dialer/silent.conf,
conf/diler/at_home.conf, conf/dialer/near_train_station.conf, ...

And then the preferences service will try to get the parameter from the
list of activated contexts files.

The context service will be used to provide the list of current
activated contexts (this is your central manager daemon)

For the roadmap : I think first it is important to have the preferences
service working correctly, and to have zhone use it.
Then we can start to implement the context service.

Let me know what you think.

== Intuition ==

Sorry, I didn't try 'intuition' yet. For that I need to see how to
install geoclue and spatialite on OpenMoko.
Still I'd like to give a try, Did you run your application on an OM ?
Or is it possible to test the app on desktop ?

-charlie

On Tue, 2008-07-01 at 17:43 +0200, Emanuele Leomanni wrote: 
> Hi all,
>    I have read some suggestions about context aware applications
> (http://lists.linuxtogo.org/pipermail/smartphones-standards/2008-June/000093.html).
>   
> I like a lot Steve's proposal on the wiki
> (http://wiki.openmoko.org/wiki/Proposal_for_context_management) and I
> think that the right approach to make developers life easier on
> developing context aware applications is to decouple a signal manager
> daemon and the application GUI that exploit it.
> 
> See this image for more details:
> http://www.bitbakery.org/~lele/daemon-approach.png
> 
> A central signal manager daemon, in my opinion, should be able to
> collect and analyze all the low level context signals sent on D-Bus
> (like GPS coordinates or signals from the accelerometer) in order to
> create an higher level context signal set (not only based on profiles)
> that is more useful from a context developer point of view.
> 
> Possible examples of High level signals are: 
>       * profile changed 
>       * position changed 
>       * city left 
>       * user on movement 
>       * user is fix at one point 
>       * user in a meeting 
>       * bluetooth neighbor detected 
>       * wifi connection found 
>       * gprs off 
>       * low battery 
>       * user is calling 
>       * call received 
>       * etc... 
> 
> Inside this way of thinking come up my effort for the community:
> 
> I have developped a Context Aware Search Engine application with the
> intent of making easier local and remote researches on Openmoko
> device.
> 
> My application is divided into a daemon (the real core) which loads
> and manages all the keywords needed into the engine. It takes care of
> computing a rank value for the keys inserted basing on context
> information (for the moment just time and gps coordinates).
> The goal is to retrieve the results on user input ordered by context
> importance. So, just to give an example, if you are near the main
> train station and you enter the key 'T' it is more likely to have as
> first results the keywords "train" or "taxi" rather than "tomorrow
> meetings".
> 
> This daemon called "Intuition" comunicates via D-Bus providing the
> applications a 'lookup' method and some signals in order to retrieve
> back the results requested.
> 
> In my implementation I have also developed a simple GUI to test the
> engine and I have provided a plugin header file to let developers
> adding their own plugins to improve the capability of the search
> engine (actual plugins implemented are 'contacts','calendar','default
> items','file search','application search').
> 
> It is still a simple prototype but I hope it could be useful as a
> starting point for further implementations.
> 
> The sources are available here:
> https://www.bitbakery.org/svn/intuition/
> 
> Emanuele
> 
> _______________________________________________
> 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.linuxtogo.org/pipermail/smartphones-standards/attachments/20080702/fd1031bc/attachment.pgp>