From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RDNS_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 12657 invoked from network); 28 Mar 2020 23:09:04 -0000 Received: from unknown (HELO lists1.math.uh.edu) (129.7.128.208) by inbox.vuxu.org with ESMTP; 28 Mar 2020 23:09:04 -0000 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.92.3) (envelope-from ) id 1jIKZJ-00079D-SV; Sat, 28 Mar 2020 18:08:45 -0500 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jIKZG-00076X-Rq for ding@lists.math.uh.edu; Sat, 28 Mar 2020 18:08:42 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jIKZF-0008GW-Ad for ding@lists.math.uh.edu; Sat, 28 Mar 2020 18:08:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=CNzndTLDvILSuxuniFm/kTZ4LfAHVT8OxZVUOr2huFM=; b=KBmBNURp9wmR2FTaHA7/KvL1ii NKoBUvbFjvnJbQVHlru0lSrylCQnGKzDw3Ht1eH3EYrWGgstTroxRhFsJGglPxkQVL/lZD9LmFD90 PVRJ02z1RnjNVOBXZrQgNUWqMixKiogdfVMl2Tdg6XcQXnHnR0RcFvvwaumMMQGjhiao=; Received: from ericabrahamsen.net ([52.70.2.18] helo=mail.ericabrahamsen.net) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jIKZ7-0006G8-6d for ding@gnus.org; Sun, 29 Mar 2020 00:08:37 +0100 Received: from localhost (c-73-254-86-141.hsd1.wa.comcast.net [73.254.86.141]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id DA8FEFA15B; Sat, 28 Mar 2020 23:08:28 +0000 (UTC) From: Eric Abrahamsen To: David Edmondson Cc: ding@gnus.org Subject: Re: gnus-cloud.el References: <87zhc0v1m8.fsf@ericabrahamsen.net> Date: Sat, 28 Mar 2020 16:08:27 -0700 In-Reply-To: (David Edmondson's message of "Sat, 28 Mar 2020 19:10:24 +0000") Message-ID: <877dz4ulg4.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain List-ID: Precedence: bulk David Edmondson writes: > On Saturday, 2020-03-28 at 10:19:11 -07, Eric Abrahamsen wrote: > >> David Edmondson writes: >> >>> After some time away, I'm playing with Gnus again. In this instance, >>> gnus-cloud isn't working for me. >>> >>> Specifically, I can add a gnus-cloud storage server (on nnimap) and >>> register another server (nntp) with it. ~u causes messages to be added >>> to Emacs-Cloud and they appear to have the right kind of content. >>> >>> ~d on another machine never does anything useful (e.g. mark some >>> articles as read) because this test: >>> >>> (if (and newer (not force-older)) >>> (gnus-message 3 "Skipping outdated cloud info for group %s, the info is from %s (now is %s)" group date now) >>> >>> always returns true. >>> >>> Looking at how `newer' is calculated, it compares the group timestamp >>> from the gnus-cloud message with the current time. It's not clear to me >>> how that test is ever going to return `nil', unless I have a version of >>> emacs running somewhere in the future that updates gnus-cloud. >> >> It's true that doesn't make a lot of sense. Presumably we should be >> checking against some value from `gnus-cloud-file-timestamps' instead. > > I'm not syncing any files with gnus-cloud, so I'm not sure how that > might help. Oh, I had assumed that one of the files in that variable would be .newsrc.eld, and that timestamp would be the relevant one. But you're right -- this ought to be what `gnus-cloud-sequence' is for. > In general I would have expected to replay any changes with a higher > sequence number, irrespective of the date of the changes. That they > happened in the past is somewhat the point, isn't it? :-) > > Another problem is that after a set of Emacs-Cloud messages have been > used to replay, the emacs instance doing that replay doesn't persist the > last seen sequence value as `gnus-cloud-sequence', so the next time it > attempts to replay it will unnecessarily replay the same sequence > numbered messages again. > > Anyway, attached is a suggested patch. This makes things work for me in > some limited testing. Comments welcome! I encourage you to open a bug report and put this patch on it. As demonstrated, I don't know this code at all, and probably won't have time to go through and learn it in the next week or so -- a bug report is more likely to be seen by Lars or Ted (who I think wrote this originally, I may be wrong). Yours, Eric