From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 32726 invoked from network); 5 Mar 2022 15:50:47 -0000 Received: from mx1.math.uh.edu (129.7.128.32) by inbox.vuxu.org with ESMTPUTF8; 5 Mar 2022 15:50:47 -0000 Received: from lists1.math.uh.edu ([129.7.128.208]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nQWg8-00Av1I-Ct for ml@inbox.vuxu.org; Sat, 05 Mar 2022 09:50:44 -0600 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94.2) (envelope-from ) id 1nQWg7-005CPB-R0 for ml@inbox.vuxu.org; Sat, 05 Mar 2022 09:50:43 -0600 Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1nQWg6-005CP5-Qc for ding@lists.math.uh.edu; Sat, 05 Mar 2022 09:50:42 -0600 Received: from quimby.gnus.org ([95.216.78.240]) by mx2.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nQWg3-00HQ7Z-K2 for ding@lists.math.uh.edu; Sat, 05 Mar 2022 09:50:42 -0600 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:Date:Subject:From:To: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Jj2A0t8qrCj8qQAiDnjun3VThX9zJKVHgMTNI4rsJqY=; b=rdMNOxKUQGst06bcUZyI5VcSEi B6RyLw7Gww0zHqw/ar4WIY98ZsWr9DGGhpezVyrM1kokjPHn9AWue7EbjW6kwB4UbpNwqvjuoy4G4 E9eKYIS8eZgbtv6IbZuud09ISlV4MxODixj5ZdNiHe+I41pcBiYNkO29Lx+vIrp++aqU=; Received: from ciao.gmane.io ([116.202.254.214]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nQWfv-0002V5-MF for ding@gnus.org; Sat, 05 Mar 2022 16:50:35 +0100 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nQWfs-0003SD-Ii for ding@gnus.org; Sat, 05 Mar 2022 16:50:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org To: ding@gnus.org From: Steinar Bang Subject: The current state of gnus-cloud Date: Sat, 05 Mar 2022 16:50:21 +0100 Organization: Probably a good idea Message-ID: Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (windows-nt) Cancel-Lock: sha1:vSaFY+d+Zra+y30/O6ioksTGuPA= Mail-Copies-To: never List-ID: Precedence: bulk Just a summary of my experiences in using gnus-cloud. As a recap: gnus-cloud adds IMAP-like capabilities to Gnus nntp groups: you can see the same read, unread/ticket and replied to messages from different gnus instances. In addition gnus-cloud can sync the gnus config (which I don't want, since both ~/.emacs and ~/.gnus.el are git-versioned for me, with one branch per client), and the gnus score files. I'm currently running gnus-cloud on two separate machines, a debian GNU/linux desktop, and a windows 10 laptop. This works well for the read mark sync, not so well for the file sync (more detail below) and has an annoying effect in that the nnimap server used for sync can't use the gnus agent (this affects both the performace for reading nnimap groups and connectivity for the laptop. I have to manually enter the server buffer and open the nnimap server after a laptop sleep). I'm running emacs 27 on both machines. The gnus-cloud delivered with the gnus of emacs 27, doesn't work well, so what I've done, is: 1. Fork the emacs-27 git branch [1] 2. Replace gnus-cloud.el in the branch with the emacs 28 version of gnus-cloud.el [2] 3. Add the gnus directory of the forked emacs 27, with gnus-cloud.el replaced to the load-path [3] 4. Fix an incompatibility with emacs-27 in gnus-cloud.el [4] 5. Make file sync of gnus-cloud.el tolerant of trying to sync multiple deltas, by allowing the overwrite of existing backup files [5] In my config I have changed storage encoding from the default EPG to "no encoding", which was the only one I could make work. I've also switched off config sync, since my config is git versioned: (setq gnus-cloud-storage-method nil) (setq gnus-cloud-synced-files '((:directory "~/News" :match ".*.SCORE\\'"))) On the windows client, I ended up disabling file sync completely since the emacs rename function fails on file names with ":" in them, and the score files contains ":" as part of their file name[6][7] (the emacs rename function is used to move the existing file to a backup file before copying in the synced file): (setq gnus-cloud-storage-method nil) (setq gnus-cloud-synced-files nil) References: [1] [2] [3] [4] [5] [6] [7]