From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/81459 Path: news.gmane.org!not-for-mail From: Dan Christensen Newsgroups: gmane.emacs.gnus.general Subject: Re: I can haz cloud idea Date: Mon, 20 Feb 2012 14:20:37 -0500 Message-ID: <87ty2lgvlm.fsf@uwo.ca> References: <87fwebnzd8.fsf@gnus.org> <1swr7nl0tf.fsf@voll.uninett.no> <87mx8elugg.fsf@gnus.org> <82fwe6d7j4.fsf@gmail.com> <874numii6j.fsf@uwo.ca> <87ty2mne8r.fsf@gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1329765710 30793 80.91.229.3 (20 Feb 2012 19:21:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 20 Feb 2012 19:21:50 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M29739@lists.math.uh.edu Mon Feb 20 20:21:49 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 1RzYnz-0000EO-Jb for ding-account@gmane.org; Mon, 20 Feb 2012 20:21:47 +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 1RzYnB-0002MN-Oz; Mon, 20 Feb 2012 13:20:57 -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 1RzYnA-0002MD-3V for ding@lists.math.uh.edu; Mon, 20 Feb 2012 13:20:56 -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 1RzYn4-0007YM-IM for ding@lists.math.uh.edu; Mon, 20 Feb 2012 13:20:55 -0600 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1RzYn2-0006VA-G4 for ding@gnus.org; Mon, 20 Feb 2012 20:20:48 +0100 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1RzYn2-00089s-Dv for ding@gnus.org; Mon, 20 Feb 2012 20:20:48 +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 ; Mon, 20 Feb 2012 20:20:48 +0100 Original-Received: from jdc by jdc.math.uwo.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Feb 2012 20:20:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 41 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:MuC61jYGzmQY9ybsJBTwDKboKJs= X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:81459 Archived-At: I really think syncing an entire .newsrc.eld file is the wrong approach. On my home machine, I read lots of nntp groups, which I never want to read on other machines, so syncing that data is inefficient and risks data loss if the remote machine updates the .newsrc.eld after I've done some reading on the local machine. Similarly, I don't want my imap groups synced, since imap already handles that. Syncing this too would be inefficient and risk data loss. This definitely should be configured on a server by server basis. Lars Ingebrigtsen writes: > As for the "merging different views" -- that's not going to happen in > any meaningful way. If you're reading stuff offline on two different > machines (without ever going online), one client is going to win when > you're finally going online. If instead of diffs you upload actions like "(mark-read 12 (34 . 37) 44)" then you get lots of advantages: - very small amount of data to upload: a diff would include the old data, all the marks that didn't change, and context lines - diffs are fragile, as they might not apply cleanly if things get out of sync - this method automatically handles merging to some degree, as instead of uploading all marks for a group it only sends the changes When Gnus wants to get the marks from the server, it'll download a baseline list of marks and all of the actions, and apply them dynamically. Eventually the list of actions will get long and the baseline marks will get rewritten, but this could happen infrequently enough that the risks of overwriting other data is small. But I still think using Ted's approach might be better, especially since I think he offered to host a server. Dan