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
