[Tracker] E-Mail metadata specification, some changes have happened

[Philip Van Hoof <spam pvanhoof be>]

Hi there!

For people who are not following the WikiPage's [1] changes but who are
still interested in it.

[1] http://live.gnome.org/Evolution/Metadata

I have changed the specification in two ways.

You can find an implementation of an EPlugin for this specification
here: http://git.codethink.co.uk/?p=tracker;a=shortlog;h=push

More specifically in the src/plugins/evolution directory. The actual
EPlugin is tracker-evolution-plugin.c and tracker-evolution-plugin.h

The plan is indeed to implement several such metadata providers. Not
only for Evolution. A KMail one and a RSS-feed one are next on our list
for Tracker (we are indeed doing this for the Tracker project ourselves,
the specification if of course in no way limited for Tracker's use
only).


The changes:

DBus
----

o. I changed the interface and the path of the DBus objects. Those who
   studied the document before know that there are two objects involved
   in one metadata consumer / server situation: The manager and the
   registrar

   The manager is now:

   Interface : org.freedesktop.email.metadata.Manager
   Path      : /org/freedesktop/email/metadata/Manager

   The registrar is now:

   Interface : org.freedesktop.email.metadata.Registrar
   Path      : Chosen my the consumer app

o. Each call on the registrar now has a "modseq" parameter. This stands
   for "modification sequence". It's similar to how IMAP's QRESYNC and
   CONDSTORE works: each data update is accompanied by a modification
   sequence.

   When you register you pass the last modification sequence that you
   received.

   The service will calculate the difference since the modification
   sequence that you passed, and give you the necessary metadata that
   you'll need to get yourself synchronized, accompanied by a new
   modification sequence.

   Next time, you'll pass that modification sequence (assuming you dealt
   with synchronizing yourself properly, else you shouldn't have stored
   the last modification sequence, and instead next time retried with
   the previous one).

Ontologies
----------

o. Each application can now have a specific ontology. 

   For example KMail has a different way of doing tags than Evolution
   has. In Evolution a tag is more a key = value thing. In KMail it's
   just a label without a value. The two are for that reason not
   compatible.

   KMail has a thing called "Serial Number" for each message to uniquely
   identify it. Whereas Evolution only has a Camel URI and a email://
   URI.

   Some metadata engines just want as much info as possible, so such
   differences are now possible by just having specific ontologies.

o. A ontology that ought to be shared by all other E-mail metadata
   sources

   Like the subject, to, from, cc, status, size. These are all shared by
   all E-mail metadata sources.



-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be