[Tracker] Tracker discussions

[Jamie McCracken <jamie mccrack googlemail com>]

Hi folks,

We have been having a few discussions on issues with next version of
tracker at Guadec

We will likely have more discussions throughout rest of guadec

Issues:

1) Storage of Events in tracker and nepomuk. Events as defined by
zeitgeist include fields like URI, EventAction, EventDate.

EG File X was edited on such a date
Email y was read  on such a date
music fle z was played on such a date

The  main issue is storage of events could bloat up over time (mainly an
issue for smaller devices with limited storage)

Easy solution is to make Event tracking optional or filterable (only
include major/specific events). Also as the data is semi-persistent in
nature we can include a time limit where data thats older than limit is
expired and auto deleted (default to unlimited years for desktops or
maybe 6 months for maemo?)


2) Quad store or storing more metadata about properties such as if they
are embedded or not, when last changed (for easy replication) and
possibly their origin. This metadata is dynamic in nature and so cannot
be in the ontology as we may not know if a contact is a primary store in
tracker or a secondary indexed store where contact is already defined in
EDS or ldap or online. 

This is problematic because metadata properties are stored in flattened
tables in tracker-store for speed.

One sub-optimal solution is to store everything in both quad form and in
flattened table format but thats too expensive and cumbersome IMO

My prefered solution is to store them as additional fields in the
flattened tables. Additional fields in sqlite do not generate extra
overhead if they are not used  and if they have the default NULL value
they cause no extra storage as well.

For a boolean field you should always use NULL and not 0 to indicate
false as a NULL causes no extra storage whereas the minimum storage size
for any non-null integer is 1 byte in sqlite (there is no single bit
size in sqlite)

The last change date for a specific metadata is only relevant if its a
non-embedded user metadata value so it can remain null for indexed
metadata and thus cause no extra overhead (indexed metadata last change
date is always the last mod date of the entity)

Likewise origin wont be relevant for many fields so can be null if its
of local origin. Im not even sure if we need origin



3) Volume IDs

We need to store volume info for files on removable or usb disks

Ideally we will use integer Id values which link to a volumes entity
with Hal/Devicekit UUID strings. 



jamie