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 julian.reschke@gmx.de
 designates 213.165.64.22 as permitted sender)
Message-ID: <4F4540DB.9030303@gmx.de>
Date: Wed, 22 Feb 2012 20:24:11 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: dev@jackrabbit.apache.org
CC: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
Subject: Re: [jr3 optional features]
References: <4F453484.9030203@apache.org>
In-Reply-To: <4F453484.9030203@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 2012-02-22 19:31, Michael D�rig wrote:
>
> Hi,
>
> Another point that came up at last week's F2F was that jr3 should - in
> contrast to jr2 - not implement all optional features of the JCR
> specification. Rather should we concentrate on the "core" features and
> improve them wrt. jr2.
>
> With core features I refer to the features which have proven vital in
> applications using Jackrabbit. With improvements I mean issues we
> identified with core features (e.g. the notable performance degradation
> with big list of direct child nodes).
>
> Looking at the list of repository descriptors [1] we could decide for
> either of them what we want to support. Here is my take:
>
> write.supported = true
>
> identifier.stability = identifier.stability.session.duration
>
> option.xml.export.supported = true
> option.xml.import.supported = true
>
> option.unfiled.content.supported = false

What's the problem with unfiled content?

> option.versioning.supported = true
> option.simple.versioning.supported = true
>
> option.activities.supported = false
> option.baselines.supported = false
> option.access.control.supported = true
> option.locking.supported = true (but we might want make exceptions in a
> clusterd environment)
> option.observation.supported = true
> option.journaled.observation.supported = true

What about the cases where current Jackrabbit fails, due to not 
sufficient information being preserved?

> option.retention.supported = false
> option.lifecycle.supported = false
> option.transactions.supported = true
> option.workspace.management.supported = true
> option.update.primary.node.type.supported = true
> option.update.mixin.node.types.supported = true
> option.shareable.nodes.supported = false

Well, shareable nodes do not really work in the current Jackrabbit... 
That being said, it shouldn't be hard to implement them properly when 
starting from scratch.

> option.node.type.management.supported = true (but with restriction wrt.
> nodes type in use)
> option.node.and.property.with.same.name.supported = true

That's something I would kill.

> node.type.management.inheritance = true
> node.type.management.inheritance.minimal = ?
> node.type.management.inheritance.single = true
> node.type.management.inheritance.multiple = ?
> node.type.management.overrides.supported = ?
> node.type.management.primary.item.name.supported = true
> node.type.management.orderable.child.nodes.supported = false
> node.type.management.residual.definitions.supported = true
> node.type.management.autocreated.definitions.supported = true
> node.type.management.same.name.siblings.supported = false
> node.type.management.property.types = ?
> node.type.management.multivalued.properties.supported = true
> node.type.management.multiple.binary.properties.supported = true
> node.type.management.value.constraints.supported = false
> node.type.management.update.in.use.suported = false
> query.languages = ?
> query.stored.queries.supported = ?
> query.full.text.search.supported = true
> query.joins = ?
> level.1.supported = true
> level.2.supported = true
> option.query.sql.supported = ?
> query.xpath.pos.index = ?
> query.xpath.doc.orderable = ?
>
> Michael
>
> [1]
> http://www.day.com/specs/jcr/2.0/24_Repository_Compliance.html#24.2%20Repository%20Descriptors
>
>