Plasma on MID, take 2

[Emmanuel Lepage-Vallée]

*Aaron J. Seigo wrote:
*

 > i can think of a few possible lines of research that could be interesting:
 >
 > * allowing the user to form topical groups of their own and access these
 > quickly; this is the concept of Activities on the desktop, really, though it
 > would look and behave slightly different on small devices: instead
of showing
 > the actual widgets it would probably show launchers. otherwise, same concept.
 >
 > * keeping track of what apps are run when; perhaps they consult the
restaurant
 > application most often around lunch and dinner times? :)
 >
 > * keeping track of which apps they use at the same time or after another one
 >
 > the latter two would mean collecting bits of data and coming up with results
 > based on them. all of the concepts above make the account/device
conform over
 > time to the user.
 >
 > they may even be useful/interesting on the desktop as well.

-Or using location based probability if a GPS is present. If the user use
his business/pim related application more often around the nearest coffee
shop, his work place or a certain restaurant, some applications can be
loaded.

-Using bluetooth. When your laptop is open near you or many of your coworker
laptop are (akonadi can be user here?). Some application have more chance
than other to used.

-Wifi access point if GPS is not present, it can replace GPS if the spot are
named (excluding dlink, ng****, linksys and other default name).

-Even light sensor can be used here, but that is less precise.

But there is a problem here, the order of application -need- to stay the
same over time or it will be a pain to find an application that is not in
the top line. A simple solution exist here. having some kind of dual way of
selecting application:

..222..222..222.222..222..
-------------------------
..000..000..000..000..000.
..000..000..000..000..000.
..000..000..000..000..000.
..000..000..000..000..000.

Where 222 are the most probable applications and 000 in a constant
predictable order.

To achieve that, we need a way to store massive amount of volatile data: all
bluetooth ID, wifi spot, gps location (and information about the place
itself), log of each application used (and when), all file used (and when
and the category of the file) and keeping track of nearly everything. Of
course, bluetooth and wifi spot need to be remove if the device did not
enter in contact with them in let say 2 month (and it is not linked to a
contact, like p2p bluethoot file transfer). Is nepomuk able to keep and use
that much information? A small SQLite database can, but it should be better
if it is linked to nepomuk in some way (gathering information from both in
the code but not having both talking directly?).

I did that kind of semantic algorithm in one of my project (not public yet,
I will work few more month on it before talking about it). I can do it
again, but I am not sure if I have time this years for an accurate one (too
simple prediction are not really accurate, at least in my previous attempt).
And again, the resources come into play. As I said in previous mail, I see
the future of computer in this semantic dimension, but are current
generation of MID able to do that much real time information gathering? We
talk about a lot of infinite loop here (with sleep, of course), but checking
all those factor every 5 second will prevent the CPU to go truly idle. In
the future, with better batteries and massive multicore chips, the problem
will solve itself, 1 low power core can be dedicated to that and other more
powerful one will stay idle, but current CPU are not build like that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20090329/6ee2197b/attachment-0001.htm