jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Handling namespace mapppings
Date Fri, 30 Mar 2012 13:03:24 GMT
hi jukka

> The trouble with this is that it's *repository*-level information,
> i.e. shared by all workspaces.

exactly... that's what i keep saying.

> Thus putting the data actually at
> /workspaceA/jcr:system would mean that we need to maintain
> synchronized copies at /workspaceB/jcr:system, /workspaceC/jcr:system,
> etc.

i am not asking for having synchronized copies. you got that wrong.
my take on this is that the structure on the mk would be like:

+ repo
   + jcr:system
     + jcr:versionStore
     + jcr:nodeTypes
     + jcr:namespaces
     + jcr:privileges
   + workspace1
   + workspace2

however, on the oak-core layer that would be mapped into the view
that is presented to oak-jcr and this is what every single
Session on oak-jcr is being looking at:

+ jcr:root
  + jcr:system
  + ...

it wasn't transparent to the JCR Session that the information
underneath jcr:system is repository-level information.

registering a new node type or a new namespace would then be
just adding the corresponding jcr items... but on the oak-core
level this was properly resolved and validated and ultimately
stored in right location on the mk.

imo it's is not sensible to give this responsibility to oak-jcr.
we should however keep that in oak-core in order to make it
easy to have other jcr-like implementations on top of oak-core.

> Thus the way I see it, this information should be kept only in one
> repository-wide place, and the oak-jcr layer would then be responsible
> for mapping this location to a virtual (read-only) /jcr:system subtree
> under each workspace.

well, here comes our disagreement. imo a session on oak-jcr would
never see the complete repository as it is bound to a workspace.
the information what is exposed by that workspace is the responsibility
of oak-core and that's basically also the reason why i had the
login-method that contained a workspace name.

kind regards

View raw message