Stefan Seifert wrote >> Lets assume we have >> /conf/global/set/a >> /conf/project/set/b >> /conf/project/foo/set/c >> >> and the context resource points to /conf/project/foo and you want all >> children of "set", then I assume the inherit property is only changed on >> /conf/project/foo/set. If that is false, nothing happens. >> If it is true, it would be checked on /conf/project/set and if there is >> one with true or if there is no property /conf/global/set is checked as >> well. >> >> If this understanding is correct, then if inheritance is not turned on, >> the only performance impact is a single property check on the inner most >> configuration resource. I think that is fine. >> >> If inheritance is used, the performance impact is higher, but then I >> think the impact of the inheritance itself is higher than the property >> check. So I think we are fine there as well > > the current implementation is this: > > - if you have no property set no inheritance takes place > - but the property may be set on any level - e.g. on /conf/global/set > - that means in the case above all 3 resources have to be checked even if no > property is set - because it is possible that it is set on any higher level. > the usecase is you may want to switch on inheritance globally or for a > brand/region/whatever. > - if inheritance takes place, it inherits all resources from all config > levels, not only from the direct hierarchy parent, unless it hits a hierarchy > config node where inherit is set to false explicitly > > what can we do? > > a. accept the performance penalty on each configuration resolution > b. check the inheritance property only on the "innermost" config resources > e.g. /conf/project/foo/set ignoring properties on all other levels unless > they are references directly. it is no longer possible to switch on > inheritance globally for a config name. > c. define whitelists of configuration names where inheritance is allowed > d. allow values true|false|inherit for the inherit property - but this has > the same problem as b. and disallows switching it on globally or per region. > e. only inherit from "direct hierarchy parent" as you suggest, chain > inheritance only if all hierachy parents have inherit=true. this again > disallows switching it on globally. >
I think this boils down to who specifies whether inheritance is wanted/needed? I think that this should be in the control of the most specific configuration. In the example above the one who configures project/foo should have the power to decide whether to enable inheritance for "set" or not. Let's assume you don't want inheritance, so you don't specifiy the "inherit=true" flag on project/foo/set. Everything works fin. With a global mechanism like a) if now someone sets "inheritance=true" on /conf/global/set it would mean that inheritance is enabled for "project/foo" which then might result in unexpected behaviour. If we think that inheritance is used sparsely then I think e) is the best option - at least it is easy to understand. If you want to have inheritance all over the place, it means that you have to set the correct property all over the place. But then, this is still the approach with less magic or hidden behaviour. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
