Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of mueller@adobe.com designates
 64.18.1.189 as permitted sender)
From: Thomas Mueller <mueller@adobe.com>
To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
Date: Thu, 5 Jul 2012 11:19:07 +0100
Subject: Re: Notes from the Oakathon
Thread-Topic: Notes from the Oakathon
Thread-Index: Ac1al6QiFbXnEVnSRJWGqq++86tNJA==
Message-ID: <CC1B3247.2F3E7%mueller@adobe.com>
In-Reply-To: <259357F8-EB04-4889-A3D1-FDCBF241DA06@adobe.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.2.120421
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi,

I agree with Felix. I don't currently see a need for Sling to "bypass" the
JCR API. If that would be needed, there is something wrong with the JCR
API or the JCR implementation.

About indexing:

> Another potential Sling extension would be a custom Oak index provider
> for optimizing the kinds of queries Sling uses.

I'm not sure what you mean here. I don't see Sling having it's own index
*mechanism*. Probably Sling will need specific indexes, but that's just
configuration, and not implementation (code). Sling should create the
indexes it needs just like any user application. I think indexes should be
configured within the repository (as nodes), so that the regular JCR API
could be used. To simplify the index configuration, we might create a
"index config tool / library" (with it's own API), but this tool should
just use the JCR API internally, no shortcut directly into Oak (for
multiple reasons, for example so we don't need a separate remoting for
it). Such a tool could be used by any kind of application, it's just
helper classes to create / manipulate nodes within a repository; it would
use the regular JCR API.

Regards,
Thomas