From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/55588 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap and crossposting (Re: Moving from nnml to nnimap...) Date: Sun, 04 Jan 2004 16:13:33 +0100 Sender: ding-owner@lists.math.uh.edu Message-ID: References: <87he0ur0yg.fsf@enki.rimspace.net> <4nisl9envb.fsf@lockgroove.bwh.harvard.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1073229253 7583 80.91.224.253 (4 Jan 2004 15:14:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 4 Jan 2004 15:14:13 +0000 (UTC) Cc: ding@gnus.org Original-X-From: ding-owner+M4128@lists.math.uh.edu Sun Jan 04 16:14:10 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Ad9xB-0000qB-00 for ; Sun, 04 Jan 2004 16:14:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1Ad9wx-0001Lq-00; Sun, 04 Jan 2004 09:13:55 -0600 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1Ad9wo-0001Kn-00 for ding@lists.math.uh.edu; Sun, 04 Jan 2004 09:13:46 -0600 Original-Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by justine.libertine.org (Postfix) with ESMTP id 2FDEA3A0027 for ; Sun, 4 Jan 2004 09:13:45 -0600 (CST) Original-Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id i04FDiAU000550 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 4 Jan 2004 16:13:44 +0100 Original-To: Ken Raeburn Mail-Copies-To: nobody X-Hashcash: 0:040104:raeburn@raeburn.org:1d272f95ae652624 X-Hashcash: 0:040104:ding@gnus.org:97422b02d4eafcce In-Reply-To: (Ken Raeburn's message of "Sat, 03 Jan 2004 22:28:46 -0500") User-Agent: Gnus/5.1005 (Gnus v5.10.5) Emacs/21.3.50 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:55588 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:55588 Ken Raeburn writes: > Simon Josefsson writes: >>> My experimentation so far (playing with imtest, don't have the guest >>> account and nnimap config set up yet) seems to indicate that the marks >>> won't be propagated. If this is the case, I think it would be a good >>> idea for the documentation to indicate this. >> >> IMAP doesn't understand the concept of crossposting, I think, so this >> sounds normal. How does crosspost mark propagation work for nntp >> groups? > > Using the xref header, I believe, which as far as I can tell, is > generated on the fly for nnimap, and only lists the current group. Ah. > I wonder, is there a way to go through all the groups and ask the > server if a certain set of message-ids are present in each? Yes, iterate over the Gnus groups and use `imap-search' for each group. E.g., (imap-search "HEADER Message-Id foo@bar" nnimap-server-buffer). > It would probably be painfully slow if there are a lot of groups > (I've got over 200 groups in my nnml hierarchy), and would require > either staying connected until all the groups are scanned or storing > the data in some magic place so the scan can be resumed if > interrupted. Yes, it doesn't sound like a realistic plan for a default behaviour, but might be implemented as an add-on workaround. > Worst case, perhaps Gnus could create a variant on the Xref header, > which says which folders the article was going to be copied to, and > leave out the message numbers, but that presumably requires Gnus to > download, edit, and upload each message, and it wouldn't work with > something like Sieve doing the refiling as messages come in, which is > where I'd prefer to get eventually. Hm. What about: when marking an article, use the current nnimap-split-rule to determine which groups would receive the current message, and then use the imap-search logic above on only those groups, to find any crossposted copies? Will probably be rather slow anyway, and assumes nnimap-split-rule knows about all split rules, but it is an improvement. >> I suspect it might be possible to implement something like it >> for nnimap by looking in the nnmail message-id split log when applying >> marks to a group (i.e., for each article with new marks, look up the >> message id in the split log and find out what other groups it was >> crossposted to and apply the same mark to it). > > That means this split log would have to be permanent, not per-session, > so I could read (and mark expirable across groups) in this session a > message I got during the last session. That per-server data will get > very big, and slow to scan. I think the nnmail split-log already is permanent, it is used for, e.g., `nnmail-split-fancy-with-parent' which have similar needs (e.g., find destination groups for earlier messages based on message-id). > And it would need to be shared between different client systems one > might run Gnus on. On the one hand, that might not be much worse than > the .newsrc.eld file, but I'd kinda like to be able to browse my mail > on my home server from my Gnus session at work on occasion, and vice > versa, and they really shouldn't have to share all the .newsrc.eld > data. And isn't it part of the point of IMAP that such data lives on > the server? Yes. It would only work if you only use one instance of Gnus, and it does all the splitting, or if you somehow synchronize the information between all Gnus instances. So here is a more IMAPish, but still Gnus-specific, idea: When nnimap crosspost split an article into several groups, it add client-specific message flags on each message, indicating the mailbox and article number of the other crossposted copies. For example, if article 4711 in mailbox INBOX.foo have a mark gnus-crosspost-INBOX.bar-42, then when marking INBOX.foo:4711 the same mark be applied to INBOX.bar:42 as well. There is one immediate problem: article numbers may change over time. Therefor, perhaps just indicating the destination mailbox name might be enough, and after knowing the mailbox name, the imap-search logic above could be used. Alternatively, the mark can contain UIDVALIDITY too, and nnimap would only try to set the mark on the other articles if the destination group have the same UIDVALIDITY and the UID still exist. The latter alternative would fast, the only delay is opening all other groups to set flags in. A minor problem would be that these crosspost marks are never garbage collected, so they will stick around forever. Perhaps that's OK.