Re: Gnus Cloud

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 09 Feb 2011 11:24:37 -0800 Lars Ingebrigtsen <larsi@gnus.org> 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 <julien@danjou.info> 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