Plasma on MID, take 2

[Emmanuel Lepage-Vallée]

Hi, sorry for not sending news int he last few day, I am not dead, just in
exam week. I don't have much time to do anything on the proposal until
Saturday (too late for update). But about the way of selecting favorite
application, I did sat down and think about it. I think the best way, for
now, is the most simple one: most used apps and user selected favorite. It
is not perfect, but it is the best simple way of doing it and we have to
admit it, even compared with the most crazy algorithm, it win. But I also
found a way (I think) of making the geolocaion/wifi/bluetooth concept fit
into less than 1mB of data and few calculation. By using profile, linking
them and merging them, I think I can make something that can produce 15
profiles and associate them with area or wifi spot with some level of
accuracy. It use basically use "base" GPS coordinate and do a triangle to
(x, y) mark a location. Like that I can save a lot of space by using smaller
length binary integer. The system would keep 16 base coordinate and would
drop less frequently used one if it need place. A new one is created when
the user go over the maximum range of other points. The triangle would use
100 for 1 (in meter) so an area would be 100x100 meter, solving the area
size problem. The integer would be formatted like that: 10bit for x and 10
for y, making a 100km range for each base point. So the whole goelocation
system can fit in 24bit (4+10+10). The last base coordinate (16) will be
dedicated to wifi spot. The last 20 bit will contain, in that case, an
hashed version on the spot name, or a part of the mac address. 20 bit is too
few to store any accurate information, but there is probably a way to have
90%+ accuracy based on probability, this is not yet clear how.

After that, it will build an application index. The index will link an
application with an integer (on 8bit (0-256)). Each applications would be
followed by a use counter in 8 bit.
Time will be in cut in 20 minute tranches in a 6 bit in length integer. (0 =
0:00, 1 = 0:20, 3 = 1:00)

A typical entry will look like:
basepoint;x;y;time;app3(count);app3(count);app3(count);endFlag
16;wifi;time;app3(count);app3(count);app3(count);endFlag
Both of these entry will fit in 74bit, it can be more or less depending on
the number of applications.

This would grow quickly and become quite big. But grouping/merging those
profile is easy. When the device is charging, a grouping and merging task
can be lanched. Merging will take 2 entry with the same / close location and
same / close time and will fusion both app list into 1 new entry and will
drop the old 1. Grouping would take many entry with similar application list
and link location and time. The file would be splited like that:
section1: app index
section2: location index (with a counter on 6 bit (not present the normal
entry))
section3: time list (many time 6 bit followed with an endFlag)
section4: profile with a 8bit index and a unix time integer to keep the last
time the profile was used.
section5: normal/unsorted/new entry
Each location or time would be linked to 1 profile (making possible to have
many time the same location/time, but it is a problem). Grouping will take a
bunch of simillar profile, merge the application part and send each location
and time to section2 and 3.

The new counter introduced in section 2 will allow to drop rarely used
location. The unix time in section 4 will allow to drop rarely use profile.
Fanally, section5 entry with low use count would be dropped too. The droping
would be made every month. It will drop newer entry, but it should not
affect result that much. Those montly cleaning and merge/gouping (every time
the device is charging) should keep the file small.

____

I think it solve the data problem. It may not be perfect yet, but it is the
best solution I found. I don't plan to make this algorithm this summer. My
current proposal will require a lot of time in his current form, I don't
want to add too much stuff. This algorithm is something that can be done
later. After all, proposing few application may be the most complex part,
but it is not the most important. Having an usable, solid and flexible way
of building netbook and MID interfaces with plasma is really my goal for
this years.

Anything I can do (that does not require too much time, I have important
exam until friday) to improve my proposal and have higher chances of seeing
it accepted?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20090402/c0649554/attachment.htm