From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/8742 Path: main.gmane.org!not-for-mail From: Paul Franklin Newsgroups: gmane.emacs.gnus.general Subject: Re: IMAP revisited Date: 11 Nov 1996 15:05:51 -0800 Organization: Computer Science, U of Washington, Seattle, WA, USA Sender: paul@fester.cs.washington.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035148868 14112 80.91.224.250 (20 Oct 2002 21:21:08 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:21:08 +0000 (UTC) Return-Path: Original-Received: (qmail 30569 invoked from smtpd); 11 Nov 1996 23:23:40 -0000 Original-Received: from ifi.uio.no (0@129.240.64.2) by deanna.miranova.com with SMTP; 11 Nov 1996 23:23:39 -0000 Original-Received: from sunsite.auc.dk (news@sunsite.auc.dk [130.225.51.30]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 12 Nov 1996 00:05:56 +0100 Original-Received: (from news@localhost) by sunsite.auc.dk (8.7.5/8.7.3) id AAA03696 for ding@ifi.uio.no; Tue, 12 Nov 1996 00:05:53 +0100 (MET) Original-To: ding@ifi.uio.no Original-Newsgroups: emacs.ding Mail-Copies-To: paul@cs.washington.edu Original-Lines: 31 X-Newsreader: Red Gnus v0.47/Emacs 19.34 Original-Path: fester.cs.washington.edu Original-NNTP-Posting-Host: fester.cs.washington.edu Xref: main.gmane.org gmane.emacs.gnus.general:8742 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:8742 >>>>> Sudish Joseph writes: > Scott Blachowicz writes: >> 3) don't have active files, etc on the server. IMAP doesn't have to change to deal with this; LIST and EXAMINE can be used. However, it will be slow if the user has many mailboxes, as a EXAMINE will be needed for each mailbox. >> 4) can maintain sequences/marks/etc on the server. That's what nn*-request-update-info was created for. I think. It at least provides a way for gnus to find out about changes on the server, but I don't know if it allows gnus changes to propagate to the server. This depends on when it is called. > Essentially, Gnus has to stop telling backends what the article > number of a message should be. For starters. I think this is too fundamental to Gnus to change. However, the mapping between Gnus message numbers and IMAP4 UIDs is the only thing which needs to be stored locally to make this work. (UIDs would work if they didn't have gaps. But I think some IMAP4 servers use time-based values, and this leaves lots of gaps if you don't come close to receiving one message per second.) A lot of this could probably be patched over depending on when nn*-request-update-info is called. (Lars, is this documented yet? It isn't in red 0.47.) The real killer is cached articles. --Paul