Re: Proposing Tracker for inclusion into GNOME 2.18

[Jamie McCracken <jamiemcc blueyonder co uk>]

Ross Burton wrote:
> On Tue, 2006-10-24 at 20:04 +0100, Jamie McCracken wrote:
> > 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.
>
> Can you point to the API in the source?

The full dbus api is :
http://cvs.gnome.org/viewcvs/tracker/data/tracker-introspect.xml?rev=1.12&view=markup

in the source, all the dbus interfaces start with tracker-dbus-* in 
src/trackerd directory so files interface would be  tracker-dbus-files.c

> > > 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?
>
> Contacts don't have a URI, and contacts have have none, one, or many
> email addresses.  In EDS, contacts have UIDs which are their unique
> keys.

okay a new table might be best then.

> > 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
>
> $ grep EVC_ e-vcard.h| wc -l
> 61
>
> Two of those are false positives, but that means that there are
> currently 59 defined keys in EDS.  The version in Maemo adds another
> three keys, but vCards allow arbitrary keys.  Does Tracker handle this
> programatically?  If I add a vCard that has a number of custom fields,
> can they be stored and indexed?

you would need to define each metadata field individually that you want 
indexed

if fields dont need to be indexed then they can be stored as blobs 
either separately or as one big blob

> > > 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.
>
> vCard types are quite complicated...  The spec is something along the
> lines of:
>
> FIELD;PARAM=VALUE,VALUE,...;PARAM=VALUE,VALUE;...:VALUE;VALUE;...
>
> i.e.
>
> N:Burton;Ross;;;
>
> N is name, a structured field.  Surname, given name, title, prefix,
> suffix iirc.
>
> X-JABBER;TYPE=WORK,PREF;X-EVOLUTION-UI-SLOT=1:ross burtonini com
>
> A Jabber account, which is the preferred entry and the work entry (TYPE
> is a list of values), which appears in the first slot in the Evolution
> interface (shame on Evolution for putting that in the vCard), with the
> value ross burtonini com
>
> EMAIL;TYPE=INTERNET,HOME:ross burtonini com
>
> An email address for home that uses the Internet as transfer.
>
> Would I be able to search for all contacts that have an X-JABBER field
> where TYPE contains HOME (so FOOHOMEBAR won't match)?   A real-world
> example from the Nokia 770: give me all contacts with an X-JABBER field
> where the X-OSSO-BOUND parameter is "ross burtonini com".

You would need to completely flatten the metadata as 
Contact.HomeJabberID, Contact.WorkJabberID etc so that all metadata is 
mapped 1:1

It would be nice as tracker is a freedesktop thingie to avoid evolution 
specific naming and also to make it clean and easy for other software to 
use. Contacts also have relevance to Emails and instant messaging so 
that kind of software might wanna use these contact objects too.

A contact can only have one metadata value per type (this is a primary 
key constraint)

With everything mapped 1:1 you can then use RDF query to search them

> Is all of this possible with Tracker, or can tracker not efficiently
> store vCard data?

I think it should be okay

So basically what I would need from you is a spec for the contact object 
 detailing what methods you need and what metadata (all flattened out 
although non searchable stuff can be kept as a single blob type) they 
need then I can look at implementing it.

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