Ondřej Kuzník wrote:
> - We do not aim to minimise the number of "redundant" messages passed if
> there are multiple paths between nodes. LDAP semantics do not allow
> this to be done in a safe way with a CSN based replication system
We would like to reduce redundancy where possible. That's
On Tue, Jun 14, 2022 at 01:40:56PM +0200, Ondřej Kuzník wrote:
> It's becoming untenable how a plain refresh cannot be represented in
> accesslog in a way that's capable of serving a deltasync session.
> Whatever happens, we have lost a fair amount of information to run a
> proper deltasync yet if
On Tue, Jun 14, 2022 at 01:40:56PM +0200, Ondřej Kuzník wrote:
> It's becoming untenable how a plain refresh cannot be represented in
> accesslog in a way that's capable of serving a deltasync session.
> Whatever happens, we have lost a fair amount of information to run a
> proper deltasync yet if
On Tue, Jun 14, 2022 at 01:40:56PM +0200, Ondřej Kuzník wrote:
> It's becoming untenable how a plain refresh cannot be represented in
> accesslog in a way that's capable of serving a deltasync session.
> Whatever happens, we have lost a fair amount of information to run a
> proper deltasync yet if
On Tue, Jun 14, 2022 at 01:40:56PM +0200, Ondřej Kuzník wrote:
> It's becoming untenable how a plain refresh cannot be represented in
> accesslog in a way that's capable of serving a deltasync session.
> Whatever happens, we have lost a fair amount of information to run a
> proper deltasync yet if
It's becoming untenable how a plain refresh cannot be represented in
accesslog in a way that's capable of serving a deltasync session.
Whatever happens, we have lost a fair amount of information to run a
proper deltasync yet if we don't want to abandon this functionality, we
have to try and fill
