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 stefan.guggisberg@gmail.com
 designates 209.85.220.228 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=feyg7ERVct4JUUENUcw6LOQ5mFYbt9XyLWZ2pkIZ3NDJi/Cu1iGTQnLkx+/shMVrAZ
         bMLXkwBC7n9/b+Zp3khhmUK+NMBI3vaLSJKueAEuNyeWBqA1IY1oS4uQHxwGl9wsmFI8
         48c+nEZu3BsZaY/rXrrHWm6qussOPUqivzTDY=
MIME-Version: 1.0
In-Reply-To: <510143ac1002170948v3a7282a8p37a35d0a5f6d6b2d@mail.gmail.com>
References: <510143ac1002170948v3a7282a8p37a35d0a5f6d6b2d@mail.gmail.com>
Date: Thu, 18 Feb 2010 14:30:43 +0100
Message-ID: <90a8d1c01002180530k19fdc3e3pa4812033f85ca3f@mail.gmail.com>
Subject: Re: [jr3] SPI-based transient layer
From: Stefan Guggisberg <stefan.guggisberg@gmail.com>
To: dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 17, 2010 at 6:48 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> We currently have two parallel implementations of the transient layer
> in JCR, one in jackrabbit-core and one in jackrabbit-jcr2spi. Ideally
> we'd only have a single implementation and have jackrabbit-core
> implement the SPI instead of the JCR interfaces.

generally, +1

> That's probably not
> doable any time soon as SPI doesn't yet cover all of JCR 2.0, but we
> should still strive to reduce the amount of duplication between these
> two components.
>
> My main worry with this work is that the assumptions encoded in the
> SPI layer may not be ideal for some of the other architectural ideas
> we have in mind.

agreed. IIUC one of the major design goals of the SPI was to allow
for as many as possible diverse backend implementations, i.e. make it
easy to implement on some legacy system. this generalization probably
makes it difficult to leverage features of purpose-built highly optimized
SPI implementations (such as e.g. j3 core ;).

we'll probaly have to review the design of the SPI layer should it become
the j3 core interface.

cheers
stefan

>
> BR,
>
> Jukka Zitting
>