Complete.Org: Mailing Lists: Archives: offlineimap: July 2007:
Re: why not use IMAP FLAGS?
Home

Re: why not use IMAP FLAGS?

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: mailtags discussion list <mailtags@xxxxxxxxxxxxxxxxx>, offlineimap list <offlineimap@xxxxxxxxxxxx>
Subject: Re: why not use IMAP FLAGS?
From: Florian Friesdorf <flow@xxxxxxxx>
Date: Thu, 26 Jul 2007 17:05:47 +0200

On Thu, Jul 26, 2007 at 12:36:28PM +0200, martin f krafft wrote:
> also sprach Florian Friesdorf <flow@xxxxxxxx> [2007.07.25.1444 +0200]:
> > So in IMAP a tag would be stored as keyword I_am_a_tag (didn't check 
> > whether it
> > may contain spaces). Maildir also allows custom flags (see [1]), however, 
> > they
> > are limited to one character.
> 
> ??? and they cannot be queried from the mail user agent.
who?

In IMAP custom flags are called keywords and are stored without the leading \,
in contrast to system flags.

With maildirs, flags are encoded into the filename in ASCII order. Every
program able to read and write filenames could handle them.

> > A solution might be extended attributes see [2], they are supported on a 
> > wide
> > range of filesystems of different operating systems.
> 
> Again, these are not accessible to the mail user agent, even though
> they'd be my vehicle of choice. That, or putting the tags *into* an
> RFC822 header, which would not need *any* modification in
> offlineimap.

I think it should not be a modification in offlineimap, but in python's
mailbox.Maildir. We need an interface to mail storages, and shouldn't matter
whether its an IMAP server or a maildir folder.

> But the major problem, doing stuff this way, is that all mail ends
> up in a single folder, and I am not sure how well offlineimap (or
> even mutt [0]) deals with folders of tens of thousand messages.
> 
> 0. http://bugs.debian.org/434544

Well, if current implementations are too slow, than program code needs to be
changed...
In my opinion, it is not sane, that every program reinvents the wheel. In the
schema of MTA, MDA and MUA the following tasks are assigned to the user agent:
synchronization, storage, searching, presentation, creation, sending. (Please
complete this list).

Synchronization:
    I love the concept of offlineimap: One program is taking care, that the
    mails on my laptop are the same as on my mail server(s). If synchronization
    is unsatisfying, one knows where to check.  

Presentation/Creation/Sending:
    Mutt is taking care of that process nicely, delegating tasks e.g. to vim or
    gnupg, and it could be called the core job of a mail user agent.

Storage/Searching:
    offlineimap is using python's mailbox.Maildir - that's the place for tags
    and that's the place for searching. Then at least, python programs do not
    have to reinvent the wheel. The next step, would be libraries for other
    languages, so that accessing a maildir is not an issue of a program but
    standardized through usage of libraries.

    As long as, we want to access maildirs directly, not using a local IMAP
    server or local XYZ storage/search server, we need a common on disk format.
    I think it is not an option to put tags into the header as: it is too slow
    to open the mails and to read the headers, and mails shouldnt be changed by
    the mail user agent. In case one wants to live with the second but improve
    the first, header caches are the solution. When sharing header caches
    between applications, we are back at a common storage for metadata for files
    - and extended attributes are the solution to it. If they are
    slow/inefficient/whatever, then extended attributes need to be optimized for
    the specific filesystem.

<possibly-nonsense>
I wonder, whether the ZODB's directory storage could be adapted to enable ZODB
as a storage layer using maildirs as backend.
</possibly-nonsense>

-flo

-- Attached file included as plaintext by Ecartis --

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7-ecc0.1.6 (GNU/Linux)

iD8DBQBGqLgsgqFlIkofQ2cRAsOnAJ4lF/McZPsMZ7Hlt/190YVLawl5lwCdEgti
QNZsQkrT77l/0UcGIG5pz/E=
=d+AU
-----END PGP SIGNATURE-----




[Prev in Thread] Current Thread [Next in Thread]