jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Handling namespace mapppings
Date Fri, 30 Mar 2012 11:37:24 GMT
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.

BR,

Jukka Zitting

Mime
View raw message