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.<br>
<br>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.<br>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)<br>
<br>A typical entry will look like:<br>basepoint;x;y;time;app3(count);app3(count);app3(count);endFlag<br>16;wifi;time;app3(count);app3(count);app3(count);endFlag<br>Both of these entry will fit in 74bit, it can be more or less depending on the number of applications.<br>
<br>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:<br>
section1: app index<br>section2: location index (with a counter on 6 bit (not present the normal entry))<br>section3: time list (many time 6 bit followed with an endFlag)<br>section4: profile with a 8bit index and a unix time integer to keep the last time the profile was used.<br>
section5: normal/unsorted/new entry<br>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. <br>
<br>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.<br>
<br>____<br><br>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. <br>
<br>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?<br>