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
