From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/68463 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: mail group by author? Date: Fri, 17 Apr 2009 11:53:01 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <868wlzfcia.fsf@lifelogs.com> References: <87fxgvnz4k.fsf@escher.local.home> <86myajqjec.fsf@lifelogs.com> <87d4bb3ba7.fsf@engster.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1239986995 23202 80.91.229.12 (17 Apr 2009 16:49:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Apr 2009 16:49:55 +0000 (UTC) Cc: Magnus Henoch To: ding@gnus.org Original-X-From: ding-owner+M16898@lists.math.uh.edu Fri Apr 17 18:51:14 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 1LurHN-0005Pb-Em for ding-account@gmane.org; Fri, 17 Apr 2009 18:51:05 +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 1LurFH-0003mF-0j; Fri, 17 Apr 2009 11:48:55 -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 1LurFF-0003lr-Aw for ding@lists.math.uh.edu; Fri, 17 Apr 2009 11:48:53 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1LurF9-0003Ms-Rd for ding@lists.math.uh.edu; Fri, 17 Apr 2009 11:48:53 -0500 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1LurFZ-0005yc-00 for ; Fri, 17 Apr 2009 18:49:13 +0200 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LurF7-0006zY-AH for ding@gnus.org; Fri, 17 Apr 2009 16:48:45 +0000 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Apr 2009 16:48:45 +0000 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Apr 2009 16:48:45 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 95 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.91 (gnu/linux) Cancel-Lock: sha1:dpTd5v10A5IqEbgWZYSPABpxdxI= X-Spam-Score: -1.5 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:68463 Archived-At: On Fri, 17 Apr 2009 11:00:16 +0200 David Engster wrote: DE> Ted Zlatanov writes: >> 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. At least for IMAP, it's possible to do this kind of update without Gnus-level calls. It would probably be more efficient. Hmm, maybe it makes sense to open a second IMAP session just for registry and search updates, and refresh it periodically. That would be much better than updating things synchronously in the main IMAP session. DE> Well, having one general database for all search related things would DE> surely be a nice thing to have. But searching is just one feature; what DE> I really wanted to have in Gnus is something resembling "Filters" in DE> Opera Mail. I remember a message from Kai Großjohann years ago where he DE> praised Opera for this feature. It's an impressive mail reader, and DE> using filters instead of splitting immediately made sense to me. And DE> most importantly, filtering is not restricted to the mail headers. You DE> can filter with a full text search, including MIME parsing. For example, DE> Opera directly shows you groups containing all attachments you have DE> received, filtered according to type. DE> To do something like that in Gnus, you need an external indexer. Mairix DE> is just one possibility, but it's well suited for Gnus because it DE> directly creates the resulting mailbox, so you don't have to parse large DE> amounts of output in Emacs Lisp. Alternatively, you could surely also DE> use search engines like Lucene, Xapian, Sphinx, etc., but those would DE> need much more work to interface them with Gnus. I prefer splitting, but perhaps I'm old-fashioned. Splitting works locally and remotely, whereas indexers need to be run and maintained. Also, splitting costs are paid once and splitting rules can be complicated. By contrast, filtering rules must be cheap, so they often drop down to simple tags or a domain-specific query language (as with nnir.el). I don't know the right solution now, but I'll think about it (ETA 2020 :) On Fri, 17 Apr 2009 12:07:49 +0200 Vegard Vesterheim 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. On Fri, 17 Apr 2009 13:50:54 +0200 Vegard Vesterheim wrote: VV> I typically use several different computers, so I prefer a VV> server-side solution. One of my biggest gripes about Gnus is that VV> some meta-information (.newsrc.eld etc.) is stored on the client VV> instead of the server. I would also like that, and in fact that's where we'll end up if we develop the facilities to have a global Gnus registry (since the newsrc file can be serialized and synchronized exactly like the registry). VV> This means that the count of unread messages typically is wrong when VV> I move from one computer to another. This actually could be avoided with IMAP, because it supports flags for exactly this purpose. I don't remember why the flags are not used in preference to the local read/unread lists in newsrc.eld. On Fri, 17 Apr 2009 15:27:36 +0200 David Engster wrote: DE> One day there might even be IMAP storage in Tramp. :-) Unfortunately, plain file storage would not be a good solution for storing large data sets. This is a problem with any rsync/SSH/etc. file-level synchronization: speed, reliability, and accessibility all suffer. I think we need a way to serialize a hashtable like the Gnus registry to an IMAP mailbox and make it searchable. At least for the registry this is easy, since every piece is self-sufficient in a single hashtable. The Gnus newsrc.eld would be a bit harder to serialize. This approach essentially makes the IMAP server a weakly organized database server and each mailbox a table. I like it. Magnus, have you considered starting work on the IMAP-based file storage? Does any of the above seem interesting or are you looking for simple file persistence and nothing more? Ted