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
