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 _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
