Re: Proposing Tracker for inclusion into GNOME 2.18

[Jamie McCracken <jamiemcc blueyonder co uk>]

Ross Burton wrote:
> On Mon, 2006-10-23 at 23:21 +0100, Jamie McCracken wrote:
> > The main reason was I didn't like the way GNOME uses loads of different, 
> > inefficient and incompatible means of storing information (think 
> > Berkeley DB for EDS, MBox for emails, the zillions of small performance 
> > draining XML files used for bookmarks, history, rhythmbox's music 
> > database and many other things). So, I wanted to bring together all this 
> > stuff under one centralised database and in doing so increase 
> > performance, power and memory efficiency of the platform as a whole.
>
> I forgot to reply to this feature earlier.  Does tracker have any
> working support for first class objects yet?  If so, how are they
> stored, what is indexed, what is the API like?

Only Files at the moment. We have preliminary Email support but its not 
complete yet. The Api would be specific to each object and would be 
analogous to the methods on a class.

> I'm curious as to how this would work for contacts, as a backend for the
> EDS addressbook instead of Berkeley DB.  

For each fisrt class object, the plan is to create a dedicated dbus 
interface so in this case we would create a 
org.freedesktop.tracker.contact interface and add various methods that 
would be required (EG Get, Create, Delete etc)

For the Db, we would either reuse the Services Table or create a new one 
for contacts depending on what makes a contact unique - if its a uri 
then the services table would be reused. Is email address the unique 
field for a contact?

Next up we would define the basic metadata or properties of the object 
(EG Contact.FirstName, Contact.Surname, Contact.EmailAddress etc along 
with their types) and add these to the metadata types table

the create method for the Contact interface would normally fill in the 
values for the most commonly used contact metadata. Other values can be 
populated using the generic metadata dbus interface. It would also 
assign a unique ServiceID for the object which is used for all metadata, 
keywords and links.

Thas pretty much all there is to it. We have dbus api for adding new 
metadata types and for populating them so its easy to extend.


I'm working on a program now
> that had added a custom field to every contact in EDS, which needs to be
> indexed.  Adding a custom field is no effort with the current EDS API as
> it stores vCards literally, and indexing the field was achieved by
> hacking the summary index code and adding the field to the summary
> files.  With the "first class" contact objects in tracker, can new
> fields be added and indexed as required?

of course - everything but blob data is indexed (that is db indexed not 
full text indexed)

Metadata is stored in a separate table according to its data type (IE 
string, numeric, Date etc). We use a composite primary key (ServiceID, 
MetaDataID) and the value itself is indexed.


--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/