From: Ted Zlatanov <tzz@lifelogs.com>
To: ding@gnus.org
Subject: Re: Emacs Cloud (coverage and killed groups)
Date: Fri, 07 Feb 2014 08:24:16 -0500 [thread overview]
Message-ID: <87ppmzawe7.fsf@lifelogs.com> (raw)
In-Reply-To: <8738jvljru.fsf@building.gnus.org>
On Thu, 06 Feb 2014 18:49:09 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote:
LI> I had originally thought of the Cloud stuff being totally symmetrical,
LI> but perhaps that's not the best approach here.
LI> That is, at home I have a Gnus setup that contains a gazillion servers,
LI> and some of them are local, like nnml ones. These obviously shouldn't
LI> be replicated to other instances. Fine.
LI> But what happens to the topic topology? If we push out newsrc data that
LI> contains only these replicated groups initially (and I think that's the
LI> right solution), what happens if we move a group from one topic to
LI> another in one of the other instances? We can't just do a full new dump
LI> of the topology back to the "home" instance, because it no longer
LI> contains all the groups...
I would have a special "cloud" topic at the top level. Or a "cloudify"
per-group property (not per server!)
Groups that have "cloudify" are then synchronized, together with their
topology position. So the group would know it's under topic G, and if G
doesn't exist, it will be created. Changing the topology of a group is
a configuration change like any other. Again, this is *per group* so
you don't have a global topology map with cloudified groups.
I think inverting the gnus-cloud configuration from
global-descending-to-local to per-group is key here, but it does
complicate the interaction with the Gnus state.
LI> So I'm now thinking we have to have a strict division between one "home"
LI> instance that contains everything, and that can do full chunk dumps.
LI> And then all the other instances would just log updates
That's good. But it should simply be a choice of "this instance
subscribes to cloudified groups X, Y, and 'gmane.*'" instead of making
such special cases.
LI> The main problem, though, is that if you're not on your home instance
LI> for months, the number of incremental chunks might get pretty ... huge.
LI> But that may not actually be much of a problem.
Nowadays, probably not. Fast connections are pretty common. Even a 3G
connection is quite fast (the lowest network speed I would expect from
our user base).
Ted
next prev parent reply other threads:[~2014-02-07 13:24 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-01 4:55 Emacs Cloud Lars Ingebrigtsen
2014-02-01 10:11 ` Ted Zlatanov
2014-02-01 12:10 ` Rasmus
2014-02-01 16:49 ` Steinar Bang
2014-02-01 20:23 ` Rasmus
2014-02-01 21:37 ` Ted Zlatanov
2014-02-01 21:50 ` Andreas Schwab
2014-02-02 5:03 ` Ted Zlatanov
2014-02-02 8:23 ` Andreas Schwab
2014-02-04 12:55 ` Ted Zlatanov
2014-02-02 22:17 ` Steinar Bang
2014-02-01 20:48 ` Lars Ingebrigtsen
2014-02-01 21:43 ` Ted Zlatanov
2014-02-01 21:44 ` Lars Ingebrigtsen
2014-02-01 22:32 ` Lars Ingebrigtsen
2014-02-02 5:04 ` Ted Zlatanov
2014-02-02 5:14 ` Lars Ingebrigtsen
2014-02-02 5:21 ` Lars Ingebrigtsen
2014-02-02 17:17 ` Ted Zlatanov
2014-02-02 22:53 ` Lars Ingebrigtsen
2014-02-02 23:20 ` Julien Danjou
2014-02-02 23:22 ` Lars Ingebrigtsen
2014-02-02 23:39 ` Julien Danjou
2014-02-02 23:46 ` Lars Ingebrigtsen
2014-02-03 8:08 ` David Engster
2014-02-03 13:14 ` Tassilo Horn
2014-02-03 14:58 ` David Engster
2014-02-04 12:53 ` Ted Zlatanov
2014-02-04 13:25 ` David Engster
2014-02-06 0:49 ` Emacs Cloud (coverage and killed groups) Lars Ingebrigtsen
2014-02-07 2:49 ` Lars Ingebrigtsen
2014-02-07 8:56 ` Julien Danjou
2014-02-07 10:40 ` Peter Münster
2014-02-08 2:35 ` Lars Ingebrigtsen
2014-02-07 13:24 ` Ted Zlatanov [this message]
2014-02-03 14:53 ` Emacs Cloud Ted Zlatanov
2014-02-03 15:04 ` David Engster
2014-02-03 14:45 ` Ted Zlatanov
2014-02-02 17:20 ` Ted Zlatanov
2014-02-02 22:50 ` Lars Ingebrigtsen
2014-02-02 5:08 ` Ted Zlatanov
2014-02-05 7:46 ` Steinar Bang
2014-02-05 23:05 ` Lars Ingebrigtsen
2014-02-05 23:06 ` Lars Ingebrigtsen
2014-02-07 13:28 ` Ted Zlatanov
2014-02-08 4:13 ` Lars Ingebrigtsen
2014-02-10 8:43 ` Daiki Ueno
2014-02-10 13:32 ` Ted Zlatanov
2014-02-11 12:14 ` Lars Ingebrigtsen
2014-02-11 13:25 ` Daiki Ueno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ppmzawe7.fsf@lifelogs.com \
--to=tzz@lifelogs.com \
--cc=ding@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).