From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/41544 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: `gnus-unseen-mark' everywhere Date: Thu, 03 Jan 2002 22:45:22 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: References: <86elld3ptd.fsf@i2d.home> <86666nc1a0.fsf@i2d.home> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035176922 6685 80.91.224.250 (21 Oct 2002 05:08:42 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 05:08:42 +0000 (UTC) Return-Path: Original-Received: (qmail 18021 invoked from network); 3 Jan 2002 21:48:02 -0000 Original-Received: from malifon.math.uh.edu (mail@129.7.128.13) by mastaler.com with SMTP; 3 Jan 2002 21:48:02 -0000 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 16MFhh-0005hR-00; Thu, 03 Jan 2002 15:47:13 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 03 Jan 2002 15:47:04 -0600 (CST) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id PAA03882 for ; Thu, 3 Jan 2002 15:46:52 -0600 (CST) Original-Received: (qmail 17992 invoked by alias); 3 Jan 2002 21:46:56 -0000 Original-Received: (qmail 17987 invoked from network); 3 Jan 2002 21:46:55 -0000 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net (HELO yxa.extundo.com) (217.13.230.178) by gnus.org with SMTP; 3 Jan 2002 21:46:55 -0000 Original-Received: from localhost.localdomain ([195.42.214.241]) (authenticated bits=0) by yxa.extundo.com (8.12.1/8.12.1) with ESMTP id g03Lkp6X027410 for ; Thu, 3 Jan 2002 22:46:51 +0100 Original-To: ding@gnus.org In-Reply-To: (prj@po.cwru.edu's message of "Thu, 03 Jan 2002 15:32:31 -0500") Mail-Copies-To: nobody Original-Lines: 42 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Common Lisp, i686-pc-linux) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:41544 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:41544 prj@po.cwru.edu (Paul Jarc) writes: > Simon Josefsson wrote: >> Consider a nnml folder which two persons access. The recent mark, >> maintained by nnml.el, is the same for both persons (now, actually, >> nnml doesn't set the recent mark, but for sake of argument). The >> seen mark however cannot be stored in the backend because they would >> become the same for both persons. > > You're making assumptions about how sharing can be done that happen to > be false for nnmaildir. In a shared nnmaildir group, typically the > marks are all not shared and only the messages are, but it's also > possible to share some kinds of marks and not others. This seems to be the same as for nnimap. > If other backends cannot do this, then I think it should be those > backends that decide to not store (nor update Gnus's copy of) the > seen marks, rather than Gnus that assumes that backends are > incapable of handling it properly. Ah. Hm, I think I understand what you are saying. If the backend doesn't support the distinction between per-user and global marks, it should rely on .newsrc.eld and not touch the mark. Nnml/nnfolder would not store seen in .marks, and would not reset the info handed to it via nnchoke-request-update-info. I think I agree now. :-) It wouldn't change how anything would work. Yes. The gnus-article-unpropagatable-p etc stuff should be moved into nnml/nnfolder (perhaps nnmail) then, because we wouldn't want `seen' marks to be stored in nnml .marks. Hm, but this means the backends has knowledge about the semantics of marks, which is wrong as well. So, either Gnus assumes that backends should only handle global marks (current solution), or the assumption is that backends need to be aware that, e.g., seen marks should not be stored in the backend if it can only provide global marks. It would be nice if the backend wouldn't have to make that kind of distinction (because the backend shouldn't have to "understand" all flags Gnus uses). Ok, I now convinced myself that none of the solutions is good. Time to sleep..