jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Handling namespace mapppings
Date Fri, 30 Mar 2012 11:43:17 GMT

On 30.3.12 12:37, Jukka Zitting wrote:
> Hi,
> On Fri, Mar 30, 2012 at 10:11 AM, Angela Schreiber<anchela@adobe.com>  wrote:
>>> Basically my idea is to have the namespace registry stored in some
>>> system location (like /:system/ns) and accessed over the standard Oak
>>> API.
>> imo it should be /jcr:system/jcr:namespaces.
> I'm not totally against this, but see below.
>> if we follow the specification it was just the responsibility
>> of oak-core to make sure that repo-level information (versions,
>> namespaces, node types, privileges and the workspaces being present)
>> is exposed on each workspace underneath /jcr:system and that writing
>> that information is properly handled.
> The trouble with this is that it's *repository*-level information,
> i.e. shared by all workspaces. 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.
> 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. The repository tree would look something like
> this:
>      /:system (or /jcr:system) - repository-wide data
>      /workspaceA - content of workspace A
>      /workspaceB - content of workspace B
>      ...
> The view of a JCR session logged into workspace A in this case, would
> then look like this:
>     / ->  /workspaceA
>     /jcr:system ->  /:system (or /jcr:system)
> The reason why I prefer calling the "system" subtree /:system instead
> of /jcr:system is to make a distinction between the actual storage
> location of the repository-wide data and the virtual per-workspace
> view on that location. Using an invalid JCR name also makes it clear
> that this isn't something that's supposed to be directly exposed to
> JCR clients, but only through the extra /jcr:system mapping.

+1, I like that approach. Mapping (especially read only) sub trees into 
a host tree should be quite easy to achieve using the current tree model.


View raw message