Big +1, I never liked this approach and it can too easily be abused as a poor replacement for ACLs.
As you say, we should remove all code from the resource resolver, as well as some stuff from the feature flags bundle which relates to that code and is not used anywhere else. If we really want to add this at a later point, we have the svn revision history. Regards Carsten 2014-03-20 6:57 GMT-07:00 Bertrand Delacretaz <[email protected]>: > Hi, > > Me and some of my colleagues have been experimenting with the > sling:features support that we have now in the o.a.s.resourceresolver > bundle, and I don't like it. > > Although the concept sounds cool, we've had a number of subtle issues > that make me think that feature is not ready for prime time and should > be removed, for now. > > For example, we we had cases where a POST tries to create a new > resource foo that already exists, because foo has feature flags that > hide it from the current request. Hard to understand and troubleshoot. > > Also, I wouldn't be surprised if we bump into subtle caching issues > with this feature - what if someone sets sling:features on a rendering > script? Those are cached, so the feature would not be applied > correctly, resulting in more difficult troubleshooting. > > The sling:features support is also too similar to access control: some > users do not see resources that others do. So why not just use access > control? If using JCR, support for that is much better than what we > provide with sling:features. Not sure why we need two similar > mechanisms. > > For now, I suggest keeping the o.a.s.featureflags module, of course, > but removing all the code that uses that from the > o.a.s.resourceresolver module. > > We might revisit that later once we have more experience with feature > flags, but for now I'd rather stay simple and avoid opening a can of > worms with magic feature flags support. The longer we keep this > feature in, the harder it is to remove it. Better remove it now with > the option of re-adding later. > > People can use the featureflags module to implement any use cases that > the sling:features mechanism supports - it's just a bit less magic, > but at least it makes it very clear what's happening, and that's > certainly much easier to troubleshoot. > > WDYT? > -Bertrand > -- Carsten Ziegeler [email protected]
