On Fri, Aug 11, 2017 at 04:42:01PM +0200, Christoph Groth wrote: > This would give a triangular topology where both client1 and > client2 sync with the server, and client1 syncs with client2. Is > this a bad idea? If client1 and client2 both receive new mail > from the server, and then sync between each other, mbsync will see > the same messages appearing on both sides. Will it handle this > case? > this will yield a complete mess.
> If not, I can probably live with a linear topology (one of the clients > is always on), but this clearly doesn't scale... > "linear" in the sense that one client would be also the server for the other clients. this doesn't have higher uptime requirements than a p2p solution when you have two clients total. and you could chain this further, provided the peer pairs are always the same. if you want true N:N p2p, then you do indeed have a problem. as for client-as-server, it may be possible to directly serve the client's folders via IMAP - this would work if the server's expectations about the format are sufficiently compatible with mbsync's. pay attention to the UID schemes. the alternative is a local "buffer" imap server to which the client's folders are synced, so it can serve them to other clients - that will work, because a single store can be synced to several channels. i think the overall best configuration is one with a "shadow" imap server: an mbsync channel (partially) syncs the upstream with the shadow, while the clients then sync only with the shadow. whether the shadow runs on one of the clients or somewhere "in the cloud" is irrelevant from a topological POV - an openwrt router with a usb stick would be sufficient if it's all limited to one location. > Another question: what would happen if sometimes client1 (=slave) > syncs with client2 (=master), and sometimes client2 (=slave) syncs > with client1 (=master)? > that question makes "only limited sense", because it's way under-specified. if you expose the clients to each other via NFS, it will work just fine _if they use a shared sync state_. of course, you need complementary configurations which are adjusted to the respective "view". as before, each such channel may only ever connect the same two stores. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel