From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/76528 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus Cloud Date: Wed, 09 Feb 2011 16:01:25 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87zkq43m16.fsf@lifelogs.com> References: <87pqr1huyy.fsf@gnus.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1297288928 30130 80.91.229.12 (9 Feb 2011 22:02:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 9 Feb 2011 22:02:08 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M24875@lists.math.uh.edu Wed Feb 09 23:02:04 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PnI6s-0005a4-Os for ding-account@gmane.org; Wed, 09 Feb 2011 23:02:03 +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 1PnI6h-0005Mb-Av; Wed, 09 Feb 2011 16:01:51 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PnI6f-0005MI-Ca for ding@lists.math.uh.edu; Wed, 09 Feb 2011 16:01:49 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PnI6b-0001iN-7d for ding@lists.math.uh.edu; Wed, 09 Feb 2011 16:01:49 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1PnI6a-0004XW-0x for ding@gnus.org; Wed, 09 Feb 2011 23:01:44 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PnI6Z-0005J8-K0 for ding@gnus.org; Wed, 09 Feb 2011 23:01:43 +0100 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Feb 2011 23:01:43 +0100 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Feb 2011 23:01:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 74 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:ho6h45FoFlqDIXJs1HKXdKpohSg= X-Spam-Score: -0.7 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:76528 Archived-At: On Wed, 09 Feb 2011 11:24:37 -0800 Lars Ingebrigtsen wrote: LI> Then if you say `M-x gnus-on-the-go' on your cell phone, and it's a new LI> installation, it'll just prompt you for user name/password, and download LI> pretty much the entire .newsrc.eld file (well, the cloud-enabled LI> portion, at least). Then subsequent updates will be on the form "send LI> me all deltas since timestamp YYYYMMDDTHHMMS". The server will figure LI> out the diff between that timestamp and the current state, create a nice LI> data package, gzip it up, and squirt it out. Just do a generic "send me all deltas since X" where X can be 0. So then the client state is just (current data, last check). The time should be in microseconds. LI> Keeping the server updated would be, as I said, mostly a matter of LI> hooking into the backend marks updating subsystem. But a nice wrinkle LI> here is that these are basically ordered transactions, so you can queue LI> them up (in a file, for instance), and then squirt them over LI> asynchronously at Gnus's leisure. For instance, you might be using Gnus LI> offline, and Gnus would squirt stuff over when you go online. And if LI> cloud.gnus.org is down, Gnus can just queue stuff and send it when it's LI> back up. This stuff can be implemented in a way that's fairly robust to LI> transient failures. LI> I think the things that should be kept updated are: LI> * server definitions LI> * groups LI> * marks LI> * topic topology LI> * score files LI> * some group parameters Yes to all of these. LI> One sticky issue is whether to sync passwords. .authinfo stuff is LI> necessary to contact some servers, but passwords are way more secret LI> than the rest of the data. Even if cloud.gnus.org is https only, it LI> would still be a juicy hacking target if we just stored passwords (in LI> clear text) there. Put perhaps we could keep .authinfo.gpg stuff LI> synced? I think that area needs more thought, but the rest seems fairly LI> straightforward to me. A .GPG file could be stored. It wouldn't be synchronized, just set/get. LI> And one nice thing about this setup is that there really would be no LI> administration or data loss importance (for me). Since cloud.gnus.org LI> is basically just a cache of data you have elsewhere, if you lose your LI> cloud password, you can just create a new account. If the service loses LI> your data -- the same thing. As long as there's a way to "back up all my data to a file" and "write all my data back from a file" I think that's OK. On Wed, 09 Feb 2011 21:22:08 +0100 Julien Danjou wrote: JD> On Wed, Feb 09 2011, Lars Ingebrigtsen wrote: JD> The rest does not interest me. I will never trust any external service I JD> do not run to store any personal information. I think it should be easy (trivial) to run this service yourself, like you would an IMAP server. JD> And I think there's much important thing to do/fix in Gnus than such a JD> thing. :) I think this is very important, personally. I would put it on top of my priority list, although I had a slightly different proposal earlier (Lars' proposal is purely data-driven and confined to Gnus only, but I can fix that :) Ted