OK, thanks. This clarifies things quite a bit. regards marcel
> On Thu, Mar 21, 2013 at 3:02 PM, Marcel Reutegger > <[email protected]> wrote: > > Do we really understand well enough what the consequences > > are moving permission evaluation even further down? I.e. > > *below* the NodeState API? > > That's where I originally envisioned it to be taking place, as a > mostly transparent wrapper around the underlying storage layer (*). > > Of course back when we were originally designing NodeState, we didn't > fully realize the impact of the "invisible parent" scenario (which > Angela was right to point out), which then led to the TreeLocation > concept and related machinery above the NodeState level. The way I see > it, with better design and encapsulation we should be able to get rid > of most of that stuff. > > Of course the full consequences of a change like what's being > discussed aren't yet thoroughly understood (for example the impacts on > node builders, content diffs, the TreeLocation interface, etc. are yet > to be considered). That's why we're discussing. :-) > > *) Instead of a full wrapper, such a "secure NodeState" would/should > only be applied as the basis of TreeImpls visible to the client. > Things like CommitHooks or the search engine would still work directly > against NodeStates coming from the storage layer. > > BR, > > Jukka Zitting
