Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4F2FCF5A.3000109@apache.org>
Date: Mon, 6 Feb 2012 13:02:18 +0000
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: <dev@jackrabbit.apache.org>
Subject: Re: [jr3 microkernel] Change log consolidation
References: <CB55754F.23FB9%mueller@adobe.com>
In-Reply-To: <CB55754F.23FB9%mueller@adobe.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit


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
>