Hi, >An alternative that AFAICT achieves the same effect in perhaps an >easier to understand manner would be to use the state of the content >tree instead of changes to that state as the key concept. Instead of a >commit(changeLog, baseState) method we could have a commit(newState, >baseState) method for persisting changes.
That's what I implemented for my first prototype (sandbox/jackrabbit-j3). >PS. You might already have discussed and dismissed this idea off-list. >If yes, what was the deal-breaker? I think the deal breaker is the API, which currently uses the 'diff' style instead of the 'absolute target state' style. For me, it doesn't matter. Either way is fine (diff style or sending the full state). The diff style requires a bit less data to be transferred I guess. However, I personally wouldn't consolidate the change log currently. I don't think it's necessary, and for the normal case (which is _not_ a randomly generated change log, but a manually generated one) I don't think it will help a lot. Also, I don't currently see that would help a lot resolving conflicts. The conflicts it can resolve seem to be weird cases (my opinion, from what I know so far), which are not that important to be resolved. Why would somebody move a node twice? If he does, it's his problem (the applications problem). And why would we want to avoid a conflict if somebody deletes the intermediate node in the meantime? What I mean is, failure to merge such a case would be just fine. Maybe there are other, more important cases that I currently don't know about. I would probably not consolidate the change log, because it simpler not to. Unless it turns out to be a problem in practice (not just in theory). Still, it is an interesting idea. Regards, Thomas
