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.27 as permitted sender)
From: Thomas Mueller <mueller@adobe.com>
To: "dev@jackrabbit.apache.org" <dev@jackrabbit.apache.org>
Date: Thu, 23 Feb 2012 09:50:17 +0000
Subject: Re: [jr3 optional features]
Thread-Topic: [jr3 optional features]
Thread-Index: AczyEI0WQksQ7FTOQS6DZbwY/qOjxA==
Message-ID: <CB6BB959.25E5D%mueller@adobe.com>
In-Reply-To: <4F45F615.5090908@adobe.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,

> option.transactions.supported =3D true


Is this JTA, right? Is it really required?

> shareable nodes
> it shouldn't be hard to implement them properly when starting from
>scratch.

In my (old) prototype they caused a rather big architectural change. I
wouldn't support them if possible.


>>node.type.management.orderable.child.nodes.supported =3D false
>
>why? in CQ we rely on the ability to have orderable child nodes.

The problem is we want to support large child node lists, and for this
case keeping them ordered is expensive (possible, but more complex, and
will slow down adding/removing child nodes to such nodes by factor 2-3).

Currently, small child node lists (less than 2000 child nodes or so) are
orderable, but large ones are not.

>i would appreciate if XPATH was still being supported.

What about if we support a (to be defined) subset of XPATH? For example by
converting it to SQL2.

Regards,
Thomas