Re: Proposing Tracker for inclusion into GNOME 2.18



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/




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]