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 08:11:07 GMT
hi jukka

> 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.

we already have the same pattern for node types, versions,
configuration, activities with are on a per-repository level as
well and where the JSR 283 already mandates where they are exposed.
quoting from the spec:

"If a repository exposes node type definitions in content, then
  that repository must also support the system node (see ยง3.11
  System Node) and the node type definitions should be located below
  /jcr:system/jcr:nodeTypes".

> Some issues / ideas that came up:
>
> * I'm assuming that the Connection is per-repository. If it isn't, we
> need some other way to access repository-global data.

that's not the right way imo for the reason explained above.
JCR defines how data that is applies beyond workspace level needs to
be exposed in terms of JCR items and i would find it really awkward
to re-invent another structure on the MK-storage level.

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.

not following that will force us to add that remapping on oak-jcr
which looks wrong to me. and this is were again i would like to
stress that IMO the oak-api isn't just a validating layer on top
of the MK but rather a different level of abstraction between
the JCR API and the completely unstructured persistence/storage.
oak-core must have knowledge of the different types of mk-items:
for example registering a new node type or creating a new workspace
requires different permissions that adding a JCR node and that one
requires another permission if that node would define access control
content.

kind regards
angela

Mime
View raw message