From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/70667 Path: news.gmane.org!not-for-mail From: Vegard Vesterheim Newsgroups: gmane.emacs.gnus.general Subject: Re: That newfangled IMAP thing... Date: Wed, 08 Sep 2010 10:34:54 +0200 Organization: UNINETT. Message-ID: <1svd6gskep.fsf@voll.uninett.no> References: <87hbi25214.fsf@uwo.ca> <8739tl4dxk.fsf@dod.no> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1283934917 21938 80.91.229.12 (8 Sep 2010 08:35:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Sep 2010 08:35:17 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M19040@lists.math.uh.edu Wed Sep 08 10:35:13 2010 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.69) (envelope-from ) id 1OtG7c-0000KI-8H for ding-account@gmane.org; Wed, 08 Sep 2010 10:35:12 +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 1OtG7b-0005pA-2F; Wed, 08 Sep 2010 03:35:11 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OtG7Z-0005ov-Ph for ding@lists.math.uh.edu; Wed, 08 Sep 2010 03:35:09 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1OtG7M-0006K0-2U for ding@lists.math.uh.edu; Wed, 08 Sep 2010 03:35:09 -0500 Original-Received: from regensburg.uninett.no ([158.38.180.100]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1OtG7L-0007r4-00 for ; Wed, 08 Sep 2010 10:34:55 +0200 Original-Received: from voll.uninett.no (voll.uninett.no [IPv6:2001:700:1:0:21a:a0ff:fee1:2782]) by regensburg.uninett.no (Postfix) with ESMTPSA id D59D670528 for ; Wed, 8 Sep 2010 10:34:54 +0200 (CEST) X-Face: Vl8-zx%G~!/rC5W!BM+T]w:k.[$Zqh. Q'Af|}oZ6JAhaysP"/43eD<|.BoMETII (Steinar Bang's message of "Tue\, 07 Sep 2010 20\:16\:23 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:70667 Archived-At: On Tue, 07 Sep 2010 20:16:23 +0200 Steinar Bang wrote: >>>>>> James Cloos : > >>>>>> "LMI" == Lars Magne Ingebrigtsen writes: > LMI> Yes, we have dovecot at work, so I'll be testing with that and Gmail. > LMI> Are there other common implementations that are worth thinking about? > >> dbmail. Upstream uses sparse UIDs, but I run it patched to use dense UIDs. > > Archiveopteryx http://archiveopteryx.org/ Yes, both dbmail and Archiveopteryx are interesting solutions for IMAP, so having good Gnus support for these could be nice. There are several different dimensions along which you could organise email (sender, receiver, subject, date, content, manual sorting, etc), and you often need to combine them: "Show me all email with subject 'Gnus' sent from Lars the last month". If you have presorted the email into folders, you need to figure out which folders you need to search to find these messages. I find this concept of presorting email into actual folders cumbersome, one email message may fit into several different folders. Imagine being able to just stuff all your email into one large folder, and then having a good search engine to access this. Then you could define a set of "virtual folders" as needed, a virtual folder being no more than a predefined IMAP query. Many email clients support something like this, but I would like to see a good server side solution, so that you have access to the same set of folders on different clients. I think both dbmail and archiveopteryx are promising candidates for something like this. I know that most of is does not directly affect the IMAP client, but I would just like to bring this concept of "server-side virtual folders" into consideration. I guess there are several thorny issues here, how to make this effective/fast enough, how to administer such virtual folders via the client, etc. But I find this concept very interesting. - Vegard V -