Hi, FWIW, when this feature was first added, I had some misgivings for similar reasons (ACL confusion, caching, etc.). After having used it, however, I have changed my mind. Feature Flags may look similar to ACLs, but they are useful for a different set of use cases than ACLs. Feature flags are about "orchestrating" features. Resource access is *one* part of this orchestration, but it is not the only part.
I do think the POST servlet issue needs to be dealt with -- setting a sling:feature property shouldn't impact the current resource resolver. But that seems like a minor bug and something which could be fixed. In terms of caching, this remains IMHO a red herring. Feature flags (when implemented on the server side) will *always* make caching significantly more complex. I'm -0 on this change. Regards, Justin On Thu, Mar 20, 2014 at 10:02 AM, Carsten Ziegeler <[email protected]> wrote: > 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]
