jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: [jr3 microkernel] Change log consolidation
Date Mon, 06 Feb 2012 13:02:18 GMT

On 6.2.12 11:30, Thomas Mueller wrote:
> 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.

Yes that's certainly another issue.

> 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.

The problem here is that everyone on the list has his one favourite set 
of normal and weird cases...

> 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.

That means designing a potentially broken system ("Unless it turns out 
to be a problem in practice") right from the start...

> Regards,
> Thomas

View raw message