Re: [Tracker] [Evolution] Beagle and Tracker, letting Evolution feed those beasts RDF triples instead

[Philip Van Hoof <spam pvanhoof be>]

On Tue, 2008-12-09 at 13:59 +0100, Philip Van Hoof wrote:
> On Tue, 2008-12-09 at 18:00 +0530, Sankar wrote:
>
> Hey Sankar,
>
> I'm writing a plugin that will implement the "Manager" class as
> described here. Tracker will then implement being a "Registrar".
>
> http://live.gnome.org/Evolution/Metadata

For early visitors of that page, refresh because I have added/changed
quite a lot of it already.

This wiki page also serves as the description of the proposal. 

A experience developer should get a quite good idea of what will be
needed in Evolution:

Keeping timestamps around foreach message so that I can do a variation
of camel_db_read_message_info_records that accepts a "since" timestamp.

For example:

camel_db_message_infos_that_changed_since (db, since, callback, userd)

Something less easy is keeping track of deleted ones too. This would be
needed for the "Unset" and "UnsetMany" calls. Only thing that has to be
kept around is the UID. With direct access to IMAP I could implement
this in IMAP by searching for holes in the UID sets. For POP there's no
real other way than to just store all the UIDs or long-uids that ever
got expunged/popped/deleted and then locally deleted.

This is of course important for accurately cleaning up metadata engines
that want to accurately be aware of removed resources (removed E-mails).

This was also a painful part back when we manually parsed the summary
files: we had to scan all existing items to check if it's not in the
original summary file any longer. This meant having to parse-all,
scan-all, process-all each time we start up.

Not very nice for desktop-startup time :-(

Especially on mobile you want fast startup time and as few things as
possible to do before becoming operational. A metadata engine is of
course not "good" if it still has inaccuracies like metadata about data
that has long been removed in its stores.

Anyway, Evolution can easily log this as it's either updated by IMAP's
IDLE, unsolicited EXPUNGE events or NOTIFY, or by its synchronization
with POP or Evolution was the responsible for deleting the E-mail (or
apply this logic to E-mail protocol super X and E-mail protocol mega Y).


Let me know what you guys think ...

-- 
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