jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: oak-jcr: path handling
Date Fri, 20 Apr 2012 15:07:03 GMT
On 2012-04-19 17:32, Michael Dürig wrote:
> ... >> I do agree that in absence of local remappings, we can probably take
>> shortcuts in mapping, but do so, we still need to parse the paths (to
>> detect expanded names and identifier names).
>
> Yes, it does not save us from parsing. However it saves us from parsing
> and persisting (and having to look at) ugly long paths like
>
> /{http://www.jcp.org/jcr/1.0}system/{http://www.jcp.org/jcr/1.0}nodeTypes/{http://www.jcp.org/jcr/nt/1.0}folder/{http://www.jcp.org/jcr/1.0}childNodeDefinition/{http://www.jcp.org/jcr/1.0}primaryType
> ...

We'll need to parse them anyway. The question is where.

With respect to persistence: It would be possible to use expanded names 
in the interface, and let the MK implementation decide on how to persist.

For instance, one document management system I worked on in the past 
used namespace/name pairs as identifiers in it's API, but then 
internalized namespace names in a separate table, so that for the 
individual nodes just an integer key was needed.

I understand that we have decided to do things differently in the MK though.

> instead it would just be
>
> /jcr:system/jcr:nodeTypes/nt:folder/jcr:childNodeDefinition/jcr:primaryType

The format of the paths as transient things shouldn't matter a lot. The 
format of paths as persisted is an implementation detail. Right now we 
expose that detail in the MK API, and that's what I'm unhappy with. But 
I acknowledge it's apparently just me :-).

>> When you say:
>>
>> > The realisation of the map should live in oak-core. The effective
>> > remapping of names should be done in oak-jcr.
>>
>> I read that as:
>>
>> - oak-core will provide an API for handling namespace mappings
>
> Or maybe just a content model. But generally yes.

At some point we need to decide. If it just exposes the content then the 
mapping will reside entirely in oak-jcr.

>> - oak-core will accept MK paths and return MK paths
>
> Yes.
>
>>
>> - it's up to oak-jcr to map between MK paths and JCR paths
>
> Yes.
>
>>
>> If this is true then we will have to move the session namespace mappings
>> OAK's ContentSession, and the repository namespace registry impl into
>> OAK's ContentRepository, right?
>
> Ups... I don't get that ;-)
>
> However, if oak-jcr has access to above table (either through an API or
> through content) I think we are fine. In that case oak-jcr can:
>
> - implement registry wide namespace mapping
> - implement session local namespace mapping
> - register new namespace mappings
> - handle items with as yet unknown namespaces
> - cope with expanded forms and qualified forms
> ...

It appears the path of least resistance for now would be to

a) put all the mapping logic into oak-jcr, which includes

b) just assuming a certain place in the content tree for the mappings.

Once we have this working we can still decide what needs to be pushed down.

Makes sense?

Best regards, Julian

Mime
View raw message