Re: MailDir



Hi,

On Fri, 2005-05-20 at 06:29 -0400, Nat Friedman wrote:
> The next step, if someone wants a good project, is to build a driver
> that can index unmanaged[1] mbox files as well.

"Filter," not "driver."  A driver is something else, so I don't want to
confuse people with the terminology. :)

> As I understand it, this has the additional difficulty of requiring that
> a single file map to multiple MailMessage indexables, and I'm not even
> sure if Beagle can do this sort of thing yet (the same architectural
> changes would be required to, for example, index the contents of Zip
> files and other archives).

The biggest problem is referring to these individual messages.  Maildir
files are easy because it's one message per file, and apps like KMail
and Evolution can pretty easily open the mail based on a file URI.  No
such scheme exists for mbox files.  Do you refer to the mbox as a whole
with a file URI?  Do you tweak the file URI scheme to be something like
file:///home/joe/my-mbox?offset=101555 and hope that apps adopt it?

This is actually a similar problem for us with archive files or email
attachments.  Do we want matches to actually refer to the file inside
the archive or just the archive itself?  We may end up having to pull
apart archives (or mboxes), putting files in temporary locations and
feeding them to apps.  That becomes a slippery slope: do modifications
to documents get saved back to the archive?  What about email
attachments, which are immutable in the mail?  I'm not sure what the
right thing to do here is.

Of course, that stuff aside, I think The Right Way To Do This would be
to move the bulk of the message parsing code (using GMime) out of the
EvolutionMailIndexableGenerator class and into a more general class that
can be reused by a bunch of things.  Probably a class in Util is the
right way to go, or perhaps we should just do an EmailFilter class.
Then the Evo code, the (unused) Mozilla/Thunderbird code, and Noam's
maildir code could all use the same mail backend.

Joe




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