From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/47941 Path: main.gmane.org!not-for-mail From: Kevin Greiner Newsgroups: gmane.emacs.gnus.general Subject: Re: New agent code Date: Wed, 27 Nov 2002 23:51:07 -0600 Sender: owner-ding@hpc.uh.edu Message-ID: <3DE5AECB.3000008@xpediantsolutions.com> References: <87el9a4cro.fsf@enberg.org> <87k7j28j4q.fsf@enberg.org> <87adjy8hrj.fsf@enberg.org> <84hee6umu5.fsf@lucy.cs.uni-dortmund.de> <3DE2E7E0.3020903@xpediantsolutions.com> <84adjwwzx9.fsf@lucy.cs.uni-dortmund.de> <87smxn2st6.fsf@gtn.ru> <3DE50645.1040602@xpediantsolutions.com> <84znruitvu.fsf@lucy.cs.uni-dortmund.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1038471826 9675 80.91.224.249 (28 Nov 2002 08:23:46 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 28 Nov 2002 08:23:46 +0000 (UTC) Return-path: Original-Received: from mail-relay.eunet.no ([193.71.71.242]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18HJlF-0001pd-00 for ; Thu, 28 Nov 2002 09:11:06 +0100 Original-Received: from malifon.math.uh.edu (IDENT:mail@malifon.math.uh.edu [129.7.128.13]) by mail-relay.eunet.no (8.12.2/8.12.2/GN) with ESMTP id gAS5rc2H066636 for ; Thu, 28 Nov 2002 06:53:40 +0100 (CET) (envelope-from owner-ding@hpc.uh.edu) 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 18HHac-0008Gd-00; Wed, 27 Nov 2002 23:51:54 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 27 Nov 2002 23:52:41 -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 XAA26419 for ; Wed, 27 Nov 2002 23:52:22 -0600 (CST) Original-Received: (qmail 23158 invoked by alias); 28 Nov 2002 05:51:27 -0000 Original-Received: (qmail 23153 invoked from network); 28 Nov 2002 05:51:26 -0000 Original-Received: from h005.c001.snv.cp.net (HELO c001.snv.cp.net) (209.228.32.119) by gnus.org with SMTP; 28 Nov 2002 05:51:26 -0000 Original-Received: (cpmta 10252 invoked from network); 27 Nov 2002 21:51:14 -0800 Original-Received: from 216.12.206.223 (HELO xpediantsolutions.com) by smtp.register-admin.com (209.228.32.119) with SMTP; 27 Nov 2002 21:51:14 -0800 X-Sent: 28 Nov 2002 05:51:14 GMT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en Original-To: ding@gnus.org Precedence: list X-Majordomo: 1.94.jlt7 X-MIME-Autoconverted: from 8bit to quoted-printable by mail-relay.eunet.no id gAS5rc2H066636 Xref: main.gmane.org gmane.emacs.gnus.general:47941 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:47941 Kai Gro=DFjohann wrote: >Kevin Greiner writes: > > =20 > >>The intended behavior is as follows: >>If an article was fetched into the agent's cache, then the article's >>header will be removed from the overview at the same time as the >>article is expired. >>If an article was never fetched, then the article's header will be >>removed from the overview if the article is marked as read but not >>marked as ticked nor dormant. >>If an article is in the overview, but not in the agentview, remove it >>from the overview. >> >>The first rule is probably obvious. The second rule exists because >>gnus-agent doesn't currently keep a timestamp on when a header was >>fetched. As a result, I can't expire just a header using >>gnus-agent-expire-days. The third rule cleans up an overview that has >>gotten out-of-sync with its agentview. >> =20 >> > >Does the rest of the expiry code go by the fetched date or by the >article date? > >Normal (mail) expiry also confuses these two times (date header of >message; timestamp of nnml file on disk; time when user hits E -- Kai >can't cound). So maybe it's not so bad when the agent does the >same. > >But OTOH, if the articles are expired by elapsed time since >fetching and the headers are expired by elapsed time since their >date, that would be strange. > >Hm. > > =20 > Actually, there is no elapse time on the headers. If you fetch an=20 article then the article and header are expired after the elapse time=20 since fetching. If you have just the header, it can be expired as soon=20 as it has been read. My thoughts were that you would only expire a=20 group when recovering disk space outweighed the deletion of read=20 headers. Of course, those headers could still be recovered by=20 refetching the headers from the server. I just took a look back at the gnus-agent-expire prior to my changes.=20 The code is rather convoluted. It is quite possible that NOV entries=20 were only expirable if you had first fetched the article. It appears=20 that if you had fetched the article AND the expiration elapse time was=20 reached, the NOV entries would be deleted when any of the following were=20 true. 1) the article ID preceded the current active range 2) gnus-agent-expire-all is set 3) The article is read and not marked as ticked or dormant. I suspect that this behavior is probably close to being acceptable.=20 From what I've seen in the preceding posts, some people are seeing a=20 different behavior. One that is not intended. I'm just going to need=20 more information before I can nail down what is wrong. BTW, I'm going to be offline until the 30th or 31st so please be=20 patient with me. Kevin