From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/81444 Path: news.gmane.org!not-for-mail From: Dan Christensen Newsgroups: gmane.emacs.gnus.general Subject: Re: I can haz cloud idea Date: Sun, 19 Feb 2012 17:15:16 -0500 Message-ID: <874numii6j.fsf@uwo.ca> References: <87fwebnzd8.fsf@gnus.org> <1swr7nl0tf.fsf@voll.uninett.no> <87mx8elugg.fsf@gnus.org> <82fwe6d7j4.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1329689807 26247 80.91.229.3 (19 Feb 2012 22:16:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 19 Feb 2012 22:16:47 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M29724@lists.math.uh.edu Sun Feb 19 23:16:46 2012 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RzF3m-00029b-7g for ding-account@gmane.org; Sun, 19 Feb 2012 23:16:46 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1RzF2b-0004E9-MX; Sun, 19 Feb 2012 16:15:33 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1RzF2Z-0004Dy-Qq for ding@lists.math.uh.edu; Sun, 19 Feb 2012 16:15:31 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RzF2Y-0003FZ-3I for ding@lists.math.uh.edu; Sun, 19 Feb 2012 16:15:31 -0600 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1RzF2V-0008U4-Ot for ding@gnus.org; Sun, 19 Feb 2012 23:15:27 +0100 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1RzF2S-0001N4-VA for ding@gnus.org; Sun, 19 Feb 2012 23:15:24 +0100 Original-Received: from jdc.math.uwo.ca ([129.100.75.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 19 Feb 2012 23:15:24 +0100 Original-Received: from jdc by jdc.math.uwo.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 19 Feb 2012 23:15:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 74 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: jdc.math.uwo.ca User-Agent: Gnus/5.11002 (No Gnus v0.20) Emacs/23.2 (gnu/linux) Mail-Copies-To: never Cancel-Lock: sha1:LsPOdSkpp9yYC6RSqrsiIqTeASg= X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:81444 Archived-At: Andy Moreton writes: > Please, please do *not* add more stuff to .newsrc.eld. I agree. > That file is already over-complex, and trying to do too many > things. Keep things simple and unixy - a single responsibility for > each file. Moreover, as soon as you have multiple clients sharing data, you are bound to get into a situation where some merging is required. (E.g. I go to work and learn that my home machine hasn't synced; I've got to get work done, so I've got to make changes at work as well.) Merging is generally easier when things are stored in logically separate containers. In addition, updating single "records" should be fast, and if everything is stored in the .newsrc.eld on an abstract filesystem, that's hard, and you have to resort to storing diffs, etc, to be efficient. Even more, it's doubtful that I'm going to want to sync the full .newsrc.eld, since on some machines I'll access different servers. Sync/cloud should be configured separately for each backend, if only for efficiency. I'm also not sure that a DCVS is a magic bullet here, since we're going to need problem specific merging and updating. For example, Gnus should remember the last state it saw on the server, and propagate changes back and forth, rather than copying over the new data (in case it has also been changed by another client). I haven't looked into it closely, but doesn't Ted's gnus-sync framework seem like a good basis for continued development? This really seems to me to fit into the database point of view. I also have to say that I always liked the idea of having the backends store marks. It allows naive methods of syncing and backup to just work, and it makes the backends behave more like nnimap which is now becoming one of the most used backends. I feels to me like the syncing gnus already has to do between it's knowledge of the marks in an nnimap group and the remote server's knowledge is really similar to what needs to happen for other backends in a cloud set-up. This is also closely related to the plugged/unplugged/agent feature. Can all of this be merged into one concept? 0) Gnus doesn't store any marks in the .newsrc.eld. 1) On startup, Gnus asks the backend for the marks, and displays the group. 2) As the user changes things, Gnus keeps track of the changes made to marks. 3) As various intervals, Gnus syncs the changes to the backend. Being "unplugged" which just mean deferring any syncs. The user could configure the backend to be nnimap, which already handles storing the marks on a server. Or the user could configure the backend to be nnml, with marks just stored locally. Or the user could configure the backend to be nnml, with marks stored on a server (e.g. Ted's LeSync idea, or some other remote storage). It really seems like getting all the marks out of .newsrc.eld and putting them in the backends would unify many ideas in Gnus. (And by default, servers could just store marks in a file like .newsrc.server-name.eld, using nnoo common code, so there wouldn't need to be code duplication in the backends. Even the default syncing code could be in common, but overridden by servers like nnimap that have a custom way to store marks.) Dan