Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of mueller@adobe.com designates
 64.18.1.181 as permitted sender)
From: Thomas Mueller <mueller@adobe.com>
To: "dev@jackrabbit.apache.org" <dev@jackrabbit.apache.org>
Date: Tue, 28 Feb 2012 15:40:03 +0000
Subject: Re: [jr3] Tree model
Thread-Topic: [jr3] Tree model
Thread-Index: Acz2Lz6DhnHswyDESImlBhD2zE+hlA==
Message-ID: <CB72B17C.266AA%mueller@adobe.com>
In-Reply-To: 
 <CAOFYJNbLjMTX3r2EM-iQogt99A4+UMExtUkxDcNNg-OC1vWqUQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi,

>It would basically be at a similar level as the PersistenceManager in
>current Jackrabbit. Instead of returning concrete ItemState objects
>(or JsonObject/NodeData), the storage layer would make persisted
>content available through the proposed Tree and Leaf interfaces.

So far we used the MicroKernel API (JSON / JSOP API) on the low level.

I agree the conversion between String and JSON / JSOP is problematic. To
avoid it, there is org.apache.jackrabbit.mk.json.JsopStream, and a wrapper
for the MicroKernel API: org.apache.jackrabbit.mk.wrapper.Wrapper and
WrapperBase. I prepared a few presentations, I can upload them to the
Jackrabbit Wiki once I cleaned them up.

>And since it's an interface, we could also implement features like
>virtual content without the complexities of the current
>VirtualItemStateProvider mechanism.

I think that's possible even with the current API.

One reason to use the MicroKernel API is so we can implement a native
version of the MicroKernel. See also
http://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20Jackrab
bit%203 - TBD - Microkernel portable to C:

Regards,
Thomas