From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/68458 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.gnus.general Subject: Re: mail group by author? Date: Fri, 17 Apr 2009 11:00:16 +0200 Message-ID: <87d4bb3ba7.fsf@engster.org> References: <87fxgvnz4k.fsf@escher.local.home> <86myajqjec.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1239958888 20221 80.91.229.12 (17 Apr 2009 09:01:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Apr 2009 09:01:28 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M16893@lists.math.uh.edu Fri Apr 17 11:02:48 2009 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1Lujy9-000883-11 for ding-account@gmane.org; Fri, 17 Apr 2009 11:02:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1Lujvu-0001GN-VK; Fri, 17 Apr 2009 04:00:27 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Lujvt-0001G7-0s for ding@lists.math.uh.edu; Fri, 17 Apr 2009 04:00:25 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1Lujvm-0001Kx-B5 for ding@lists.math.uh.edu; Fri, 17 Apr 2009 04:00:24 -0500 Original-Received: from m61s02.vlinux.de ([83.151.21.164]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1LujwC-0006mx-00 for ; Fri, 17 Apr 2009 11:00:44 +0200 Original-Received: from dslc-082-082-171-044.pools.arcor-ip.net ([82.82.171.44] helo=honk) by m61s02.vlinux.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Lujvk-0000j5-NU for ding@gnus.org; Fri, 17 Apr 2009 11:00:17 +0200 In-Reply-To: <86myajqjec.fsf@lifelogs.com> (Ted Zlatanov's message of "Tue, 14 Apr 2009 11:39:39 -0500") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux) Mail-Copies-To: never Mail-Followup-To: ding@gnus.org X-Spam-Score: -2.6 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:68458 Archived-At: Ted Zlatanov writes: > On Mon, 30 Mar 2009 13:57:02 +0200 David Engster w= rote:=20 > > DE> Stephen Berman 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.=20 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 w= rote:=20 > DE> Tassilo Horn 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=DFjohann 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