Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of michael.duerig@day.com
 designates 62.192.10.254 as permitted sender)
Message-ID: <4B8673FE.2000608@day.com>
Date: Thu, 25 Feb 2010 13:58:38 +0100
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <michael.duerig@day.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: dev@jackrabbit.apache.org
Subject: Re: [jr3] EventJournal / who merges changes
References: <91f3b2651002240245w124a1b27w32c8b5bb335ffb40@mail.gmail.com>
	 <4B866D02.5080406@day.com>
 <c3ac3bad1002250439n68cdc2b7pad76f4c4359e8321@mail.gmail.com>
In-Reply-To: <c3ac3bad1002250439n68cdc2b7pad76f4c4359e8321@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Alexander Klimetschek wrote:
> On Thu, Feb 25, 2010 at 13:28, Michael D�rig <michael.duerig@day.com> wrote:
>> I like this approach. In general I think merging is very difficult if not
>> impossible at all to get right and will always be based on some assumptions
>> (intended semantics). I think we should not put this burden onto the
>> micro-kernel but rather leave it to higher levels (or even end users) to do
>> the/some merging.
> 
> Doing so wouldn't prevent a specific micro-kernel implementation from
> still trying to do a merge? Because I think this could still be
> interesting when following eventual consistency models with
> distributed cluster nodes.


Sure but I think we should restrict this to the cases where 1) the merge 
semantics is 'obivious' and 2) the performance hit is neglectable.

Michael