Re: mail group by author?

[David Engster <deng@randomsample.de>]

Ted Zlatanov <tzz@lifelogs.com> writes:
> 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. 

Yes, I tested that some time ago using maphash, and it was pretty
fast. My idea was to extend nnmairix to also build groups containing all
messages which have a certain label. I still plan on doing that when the
feature freeze is over.

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

Making these kinds of "virtual" groups needs a back end which implements
the Gnus API functions. This is already implemented in nnir, so I think
extending nnir to also be able to query the registry shouldn't be
difficult to do.

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

Visiting all groups for new messages surely isn't nice, but I'd still
prefer it because it's self-contained. One could call this in the
gnus-after-getting-new-news-hook.

Using external dribble files or scripts is probably faster and more
elegant, but also more difficult to set up.

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

Well, having one general database for all search related things would
surely be a nice thing to have. But searching is just one feature; what
I really wanted to have in Gnus is something resembling "Filters" in
Opera Mail. I remember a message from Kai Großjohann years ago where he
praised Opera for this feature. It's an impressive mail reader, and
using filters instead of splitting immediately made sense to me. And
most importantly, filtering is not restricted to the mail headers. You
can filter with a full text search, including MIME parsing. For example,
Opera directly shows you groups containing all attachments you have
received, filtered according to type.

To do something like that in Gnus, you need an external indexer. Mairix
is just one possibility, but it's well suited for Gnus because it
directly creates the resulting mailbox, so you don't have to parse large
amounts of output in Emacs Lisp. Alternatively, you could surely also
use search engines like Lucene, Xapian, Sphinx, etc., but those would
need much more work to interface them with Gnus.

Regards,
David