Re: mail group by author?

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 30 Mar 2009 13:57:02 +0200 David Engster <deng@randomsample.de> wrote: 

DE> Stephen Berman <stephen.berman@gmx.net> writes:
>> Is it possible to make a temporary group consisting of mails by a
>> specific person whose mail articles may be scattered across many
>> different groups?  I would like to do this to this to be able to see all
>> mail by given people, regardless of which groups the individual mails
>> are stored in.

DE> Maybe the Gnus registry could be used for creating such temporary
DE> groups, but as far as I know there's nothing implemented yet that does
DE> what you want right away.

This is really easy to implement as far as locating the message IDs and
article groups+numbers.  The hard part is to make all those articles
into one group, I don't know how to do that.  But I can write the first
part if you need it.

On Tue, 31 Mar 2009 13:35:10 +0200 David Engster <deng@randomsample.de> wrote: 

DE> Tassilo Horn <tassilo@member.fsf.org> writes:
>> But probably the registry could jump in here (at least if I've read the
>> message in the original group before and omit virtual groups from
>> registration).

DE> Yes, I guess this could be scripted somehow, since the virtual
DE> groups are in their own namespace anyway. But indeed, the registry
DE> would have to see the original message in the original group
DE> beforehand. I already struggled with that problem with nnmairix, and
DE> don't yet know how to solve that efficiently, especially since I'm
DE> splitting with procmail on the server and not with Gnus.

The registry could periodically visit all groups to see new messages.
But that's messy.  It could also read a "dribble" file with the message
IDs and groups it needs to refresh.  The gnus.registry.eld file could
live on the server and get rsynced to the clients or opened remotely
through Tramp.

Since the registry is pure data storage, it is not hard to serialize it
to and from a database.  Registry queries currently assume the data
structure is local, but that can be easily modified to query the remote.

A remote DB may in fact be the best option, either something relaxed
like CouchDB or SimpleDB, or something more constrained like a standard
RDBMS schema.  A benefit of CouchDB or SimpleDB is that users could make
their registry publically readable, so I'm in favor of that.  Tying
mairix and other search backends into the same DB is also a good idea.

On Tue, 31 Mar 2009 14:23:19 +0200 Tassilo Horn <tassilo@member.fsf.org> wrote: 

TH> Yes, I do so with SIEVE, too + some very restricted local fancy
TH> splitting with gnus-registry-split-fancy-with-parent.  Therefore it
TH> would be nice to do the registration of messages not on reading them but
TH> somewhere after fetching and splitting.

You mean after SIEVE splitting?  I don't know much about SIEVE on the
server, can you hook scripts to a step?  If yes it may be possible to
tie it into the above database discussion.

Ted