> I would like to have something which works 100% first, then try to > think about improvements.
That's reasonable. I was trying to do this back in '07 by sticking tape over the current implementation. Sounds like you're on a better path now. >> Note that both of these become much bigger issues if we want to support >> periodic (as opposed to immediate) replication or incremental backup. > > I guess that immediate replication when something change in any server > is the best solution. I personally don't have a use for periodic / delayed replication but it is currently on our replication requirements page - http://cwiki.apache.org/confluence/display/DIRxSRVx11/Replication+Requirements >> Using the current system (along with a fix for DIRSERVER-894) the >> example above would require very little overhead for server B - >> the minor change from server A would be sent over and then either >> applied or discarded based on the CSN's at the time of the >> modification. The existing modifications don't need to be rolled >> back / re-applied. > > The main issue using this technic is to analyze in retrospect what > would be the impact of a modification on the current server > considering all the later modifciations : there are many possibilities > that local modifications done after may be invalid. > > Any idea on how to deal with that ? Yeah, it does start getting very complicated to support everything. One example is: 1. Server A and B start fully sync'd with no attr1. The connection drops. 2. Server A does a replace attr1:A1 3. Server B does an add attr1:B1 4. The servers reconnect and replicate their changes. Server A would just end up with attr1:A1,B1. Server B needs some way of getting the same. I can only think of re-playing B's own logs after applying A's change really. Not far off what you're going for. I think you're 100% right really. It is definitely best to come up with something that works then we can see if we can refine it a bit and optimise for some common cases. I was only worried about this new design being implemented only to have to re-design again later on to get something optimal. Martin
