On 17.01.2012 02:28, Hyrum K Wright wrote:
> ... and something like inheritable props my fit in that model, though
> I'd had to make the feature dependency tree another level deeper.
Before you jump on the inheritable properties bandwagon, consider that
server-mandated configuration is not inherently versioned in the same
way as ordinary node properties (nor, for that matter, are ACLs).
There is a valid case for allowing modification of server-side
configuration (and/or ACLs) for existing, historical revisions, which
you cannot do with node properties today. So these attributes behave
like revprops in the sense that you can change them for an historical
revision, but like node properties in the sense that they apply to a
path and/or subtree. It's a different-but-parallel structure to node
properties.
You still want to maintain an audit trail of historic modifications,
however; so that you can ask, e.g., "what was the effective ACL of
^/foo/bar two weeks ago and who changed it since then". This trail is,
by the way, something we don't provide for revprops, but should IMO. You
could say that revprops are just a special case of this attribute that
are constrained to the repository root.
-- Brane
Received on 2012-01-21 20:11:52 CET