From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/41598 Path: main.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.emacs.gnus.general Subject: Re: `gnus-unseen-mark' everywhere Date: Fri, 04 Jan 2002 17:01:50 -0500 Organization: What did you have in mind? A short, blunt, human pyramid? 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 1035176970 7040 80.91.224.250 (21 Oct 2002 05:09:30 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 05:09:30 +0000 (UTC) Return-Path: Original-Received: (qmail 4830 invoked from network); 4 Jan 2002 22:02:54 -0000 Original-Received: from malifon.math.uh.edu (mail@129.7.128.13) by mastaler.com with SMTP; 4 Jan 2002 22:02:54 -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 16McPi-0006CF-00; Fri, 04 Jan 2002 16:02:10 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 04 Jan 2002 16:02:00 -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 QAA10272 for ; Fri, 4 Jan 2002 16:01:47 -0600 (CST) Original-Received: (qmail 4804 invoked by alias); 4 Jan 2002 22:01:50 -0000 Original-Received: (qmail 4799 invoked from network); 4 Jan 2002 22:01:50 -0000 Original-Received: from multivac.student.cwru.edu (HELO multivac.cwru.edu) (qmail-remote@129.22.96.25) by gnus.org with SMTP; 4 Jan 2002 22:01:50 -0000 Original-Received: (qmail 24681 invoked by uid 500); 4 Jan 2002 22:02:12 -0000 Original-To: ding@gnus.org In-Reply-To: (Simon Josefsson's message of "Fri, 04 Jan 2002 22:27:24 +0100") Mail-Copies-To: nobody Mail-Followup-To: ding@gnus.org Original-Lines: 50 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/20.7 (i386-redhat-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:41598 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:41598 Simon Josefsson wrote: > prj@po.cwru.edu (Paul Jarc) writes: >> ["seen"] doesn't have to do with the backend itself, but it does >> have to do with what is stored via the backend - i.e., the >> articles. OTOH, "cache" has to do with information always stored >> outside the backend. There's nothing outside the backend that >> "seen" depends on, or must be synchronized with, etc. > > You could say that ".newsrc.eld" is outside of the backend and the > seen mark depends on it and is specific to .newsrc.eld. Depending on the user's configuration and wishes, it's possible that the backend could have a more up-to-date copy of the "seen" marks than .newsrc.eld does[*], so it makes sense to store "seen" in the backend and allow the backend to update Gnus's "seen" marks. This cannot be said for "cache"; the backend does not store the cache itself, and so its copy of those marks (were they to be stored in the backend, which of course they aren't) will never be more up-to-date than Gnus's copy. So there's no reason for the backend to update Gnus's copy, and thus no reason for the backend - any backend, regardless of its capabilities - to store "cache". [*] You would probably say that the most up-to-date copy of "seen" is, by definition, always in .newsrc.eld. But note two facts: - "seen" does not carry very much meaning for Gnus (less meaning than is carried by, e.g., "expire"); it is displayed in the *Summary* buffer, and it is automatically set for new articles. That's all. - Gnus does not make it easy for the user to define arbitrary new mark types. As a consequence of these two facts, a user might want to adjust the meaning of "seen" in such a way that the backend could have the most up-to-date copy. I think it would be nice if it weren't too hard to do this. But it would be even better to allow arbitrary new user-defined mark types. So I guess focusing on "seen" is the wrong way to go anyway. >> I think such a project could also handle the de-mark-ification of at >> least "cache" and "download", right? > > That could be another step in that project. It is probably best to > unify the agent and the cache without touching marks first though. > > Maybe we should start porting Gnus to Guile and clean up the design in > the process. But this sounds like really more work. :-) Well, "cleaning up the design" sounds like it could easily include the cache/agent unification as well. :) paul