jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: [jr3 optional features]
Date Wed, 22 Feb 2012 19:24:11 GMT
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
>
>


Mime
View raw message