Re: mail group by author?

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 17 Apr 2009 22:15:33 +0200 Vegard Vesterheim <vegard.vesterheim@uninett.no> wrote: 

VV> On Fri, 17 Apr 2009 11:53:01 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote:
>> On Fri, 17 Apr 2009 12:07:49 +0200 Vegard Vesterheim <vegard.vesterheim@uninett.no> wrote: 
>> 
VV> I have great hopes for dbmail (dbmail.org). dbmail has an IMAP-backend
VV> for retrieving messages. Storing headers (and body) for mail messages
VV> into a database, opens possibilities for flexible and efficient
VV> queries and retrieval of email messages.
>> 
>> Considering the large amounts of people using IMAP on third-party
>> servers nowadays, I think it's best to find an approach that works with
>> any IMAP server.  I know this is unfair to solutions like dbmail, but
>> otherwise we end up with very limited solutions.  I think David agrees
>> with me from his followup.

VV> But dbmail *is* a IMAP server, I do not necessarily suggest any
VV> special support for dbmail in Gnus. Having a proper database as
VV> storage with search indexes for headers, instead of relying on the
VV> filesystem, will hopefully result in a IMAP server with more flexible
VV> and efficienct query and retrieval functionality. Support for virtual
VV> folders (predefined searches), is more easily accomplished with an
VV> infrastructure like this.

Sorry, I thought you were implying we should have special support for
dbmail's queries (instead of just using the regular IMAP commands).  But
the IMAP client needs at least some awareness of dbmail's abilities, no?

VV> Presorting of mail into statically defined folders is IMHO the wrong
VV> approach. I have wasted much time searching for a specific email, only
VV> to discover it was filtered into another folder than I had
VV> thought. With virtual folders, the same message can be found in
VV> several folders, but will still be stored only once, since the folder
VV> is really a query on the IMAP server. 

Managing large collections of data is expensive.  No matter how good the
database, it's slower to manage all the messages in one set as opposed
to partitioning them in some way.  In effect, "static" mailboxes are
really partitions of the full message set, and the server's storage
backend (Maildir+ or some other mechanism) handles the partitioning
transparently.

VV> Sitewide de-duplication of messages would be an added benefit of
VV> this approach.

I don't think the savings there are significant.

VV> For instance, I would like to have a folder called 'People' with
VV> automatically generated subfolders for each person having sent, or
VV> recieved, an email to/from me. I would also like to have the
VV> possibilities to define folders with names (and content) like:
VV> 'Messages_recieved_this_month', 'Messages_I_sent_yesterday' etc.

This can be done with the Gnus registry currently.  What I'm slowly
realizing is that the registry needs to be integrated deeper with Gnus
as a sort of "mail crawler" instead of an opportunistic voyeur that can
miss mail.  In addition, the registry data needs to be storeable
somewhere outside the local filesystem.

Ted