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 aklimets@day.com designates
 207.126.148.88 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <90a8d1c01002180250h40941e6cjc5d5b17cd67eecb1@mail.gmail.com>
References: <510143ac1002170748lf6e07c0w2d527f4b026dc44@mail.gmail.com>
	 <90a8d1c01002180250h40941e6cjc5d5b17cd67eecb1@mail.gmail.com>
Date: Thu, 18 Feb 2010 13:13:47 +0100
Message-ID: <c3ac3bad1002180413l7d6f2eccib74710fb5e48ef6e@mail.gmail.com>
Subject: Re: [jr3] Repository microkernel
From: Alexander Klimetschek <aklimets@day.com>
To: dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1

> On Wed, Feb 17, 2010 at 4:48 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>> Assuming we have a unified persistence layer (see the other thread),
>> it should be possible to implement a relatively simple repository
>> "microkernel" that implements just enough functionality for higher
>> level components like search, versioning, node types, observation,
>> etc. to be implemented on top of it.

+1

On Thu, Feb 18, 2010 at 11:50, Stefan Guggisberg
<stefan.guggisberg@gmail.com> wrote:
> absolutely. the SPI would IMO be an ideal starting point for such a
> microkernel api. we might need to review/strip it though.

+1

I think we should start with a scalable persistence layer (as
discussed in the other threads) and from there find the simplest API
needed for it, and then merge it with the existing SPI. An important
goal for that microkernel API would be that you can implement it
within one day (functionally, not necessarily fast), as compared with
the full JCR API, that requires many things like node types,
observation, shareable nodes, versioning etc.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com