Return-Path: X-Original-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EDEF8E399 for ; Wed, 5 Dec 2012 09:24:21 +0000 (UTC) Received: (qmail 66278 invoked by uid 500); 5 Dec 2012 09:24:21 -0000 Delivered-To: apmail-jackrabbit-oak-dev-archive@jackrabbit.apache.org Received: (qmail 66170 invoked by uid 500); 5 Dec 2012 09:24:21 -0000 Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: oak-dev@jackrabbit.apache.org Delivered-To: mailing list oak-dev@jackrabbit.apache.org Received: (qmail 66150 invoked by uid 99); 5 Dec 2012 09:24:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Dec 2012 09:24:20 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com designates 209.85.214.170 as permitted sender) Received: from [209.85.214.170] (HELO mail-ob0-f170.google.com) (209.85.214.170) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Dec 2012 09:24:13 +0000 Received: by mail-ob0-f170.google.com with SMTP id wp18so9773533obc.1 for ; Wed, 05 Dec 2012 01:23:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=+6x7Fz/1K07gSko3ubbrD6d4xiPPOJAM9snlXbUGPOM=; b=qEj4niZaXHMgsk/1SQ71q15uHihUK6PeWCRg6Cocm/4WQkOrqjkrByYNDjSJkGvHkb 0mBStitF0+VILqhgsu1tm/eo6eUHtbJfy/CS8z7fLh/U7xYF29OzcY/D5GzINuAxGTqr pRtq7vvTVHSOALULlDM5m+oLGJ2ez7MJGQYBqtrPm+qR0PMGiQ7jDGXTlihUK0+sTVdo iNvejP9sT1MCTGGT/UamFGQFXSSgZdZVUhJta4pD+fqEhsl27P94yavPkhYOQFs8H9at xq6q3F2YGajeZBNkAXzZeEBo9wXepasj3Lkc59HZ1JxfPJgLDmFNojAFrpXvMgbch+mf jc3g== Received: by 10.60.1.132 with SMTP id 4mr13666656oem.140.1354699433132; Wed, 05 Dec 2012 01:23:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.144.36 with HTTP; Wed, 5 Dec 2012 01:23:32 -0800 (PST) In-Reply-To: <9C0FC4C8E9C29945B01766FC7F9D389817293D5367@eurmbx01.eur.adobe.com> References: <9C0FC4C8E9C29945B01766FC7F9D389817293D50BC@eurmbx01.eur.adobe.com> <9C0FC4C8E9C29945B01766FC7F9D389817293D5211@eurmbx01.eur.adobe.com> <9C0FC4C8E9C29945B01766FC7F9D389817293D52A8@eurmbx01.eur.adobe.com> <9C0FC4C8E9C29945B01766FC7F9D389817293D5367@eurmbx01.eur.adobe.com> From: Jukka Zitting Date: Wed, 5 Dec 2012 10:23:32 +0100 Message-ID: Subject: Re: Oak & JCR versioning To: Oak devs Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Hi, On Wed, Dec 5, 2012 at 9:19 AM, Marcel Reutegger wrote: > I guess in the end I can live with either approach, but right now prefer > 1). maybe the tie-breaker could be the question how we actually want to > expose the version storage through the Oak API and how we implement it. I think in either case the version storage should be exposed simply as the /jcr:system/jcr:versionStorage subtree. Anyway, how about we go with your option 1), but structure the code such that we keep the CommitHook that triggers versioning operations separate from a Validator that simply ensures the consistency of changes to the version store and all versionable nodes (and would therefore also act as an independent watchdog for potential bugs in the hook)? That way potential future deployments that want more freedom at the expense of more complicated versioning could achieve that simply by disabling the auto-versioning CommitHook. BR, Jukka Zitting