Hi, @Dominik, Some other use cases could be - free features vs premium/paid features, where some features are disabled based on type of user account.
@Felix, You are right, we can temporarily enable feature. But, as we advocate more and more use of ResourceResolver api instead of underlying content storage. There could be cases where even editors/tools used in development/installers are using the resourceResolver api and never see the resource. Like exporting some content package to be deployed to another sling instance, but package exporter use resouceResolver api and never see the resource. Thanks, Amit -----Original Message----- From: Dominik Süß [mailto:dominik.su...@gmail.com] Sent: 15 November 2013 18:49 To: dev Subject: Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype) Hi Amit, maybe I haven't understood the idea of FeatureFlags right, but isn't this exactly what this is about. The system should behave if it wouldn't be there at all. The basic idea is that you don't have to branch it away during development so you can ship it in a non-productionready or non QEed state and turn it on without deployment (maybe just to a smaler audience or in the beta env). Therefore I would expect this to be completely hidden as it would like when being protected through ACLs. Cheers Dominik On Fri, Nov 15, 2013 at 2:11 PM, Amit.. Gupta. <amitg...@adobe.com> wrote: > >So, finally, I agree that baking the feature flag support directly > >into > the ResourceResolver implementation is suboptimal, it is probably > still the most comprehensive and complete solution to the > requirements. And I cannot conceive plugin hooks (at this point) to > define such that we can do feature flag plugins. > > I think that we should not put it directly into ResourceResolver, > because if resourceResolver does not give me a resource if feature is > disabled, Resource will stop existing for me. There will be no way to > access that resource using ResourceResolver api i.e. let's say I want > to remove sling:feature attribute from that resource, I can't do that. > ResourceResolverDecorator should be the way to go (implementation > could be restricted i.e. queryResources not supported), additionally > providing a servlet filter as Alex suggested. > > Thanks, > Amit > > -----Original Message----- > From: Felix Meschberger [mailto:fmesc...@adobe.com] > Sent: 15 November 2013 13:11 > To: dev@sling.apache.org > Subject: [OT] Feature flag influence on Resource access (Was: FYI: > feature flags prototype) > > Hi > > TL;DR: Long discussion on why I think Feature flag support should > currently be baked into the ResourceResolver implementation. > > I am forking of this discussion now to step back a bit and really look > into what we expect from Feature flag support in the ResourceResolver. > I go by the main resource access or methods there, so: > > * resolve() -> Resource > Calculates a virtual list of resource candidates and returns the first > one. Applying feature flags, it might not return the first one. > Another level of features could be applied to supporting feature flags > in the /etc/map mappings leading to the list of candidate resources. > > * map -> String > The input path is first converted into a resource, which may have a > feature flag applied. > In addition to applying a feature flag to the resource which is > finally mapped the /etc/map mappings can also be "filtered" with feature > flags. > > * getResource() -> Resource > For absolute path its a single yes/no question: Is the resource > visible or not according to the feature flag. > For relative paths its not as simple since the ResourceResolver > iterates the search path looking for a resource. So each canidate is > looked at and has to have its feature flag inspected. (feature flags > of ancestors are ignored; only feature flags in the candidate resource > itself are considered; so no feature flag inheritance down the tree) > > * getParentResource() -> Resource > This is not an interesting case because it accesses the parent > resource using the absolute path and we would not expect to get null > here (except if the argument resource is the root resource). > > * listChildren -> Iterator<Resource> > * getChildren -> Iterable<Resource> > * queryResources -> Iterator<Map<String,Object>> > * findResources -> Iterator<Resource> > Simple case here: We just exclude child resources whose feature flag > refers to a disabled feature. > > What options do we have ? > > * ResourceResolverDecorator (to be specced/implemented): Will have to > do extra work getResource to iterate the search path for relative > resources to consider the feature flag - might optimize by only > iterating if the actual getResource method returns a resource with a disabled > feature flag. > Iterator<Resource> can simply be decorated, too. queryResources is > harder again because this might contain results from queries which > should not be included according to the feature flag (so each entry > would have to be inspected, if at all possible). Also: A > ResourceDecorator cannot properly handle feature flags in /etc/map > mappings at all and also support feature flags on resolveResource is > probably hard to implement because the list of canidate resources is > influence by /etc/map mappings so a decorator would have to replicate that > work. > > * ResourceAccessGate: This is not leveraged by all ResourceProviders > and we expressely leave it to these services to indicate the use of a gate. > Defining Feature flag support to have all ResourceProviders require to > leverage ResourceAccessGate sounds contradictionary. Also, while a > case can be made for the Feature flag to be some kind of an access > gate, the actual idea of the ResourceAccessGate is actual access > control as in secure access. Also we just want to apply the feature > flag "gate" to all Resourceproviders not a generic ACL gate which may also be > defined. > > * Bake Feature support into the ResourceResolver implementation: This > solves the ResourceResolverDecorator problems by being able to handle > Feature flags early. But is bears the problem of overloading the > implementation with the feature flag support. > > So, finally, I agree that baking the feature flag support directly > into the ResourceResolver implementation is suboptimal, it is probably > still the most comprehensive and complete solution to the > requirements. And I cannot conceive plugin hooks (at this point) to > define such that we can do feature flag plugins. > > Is the ServletResolver also affected by feature flags ? Probably not: > The ResourceResolver does filter on resource feature flags and the > SlingScriptAdapterFactory may apply feature flags for scripting > languages and Servlet services may implement OptingServlet and query > feature flags in the accepts method. > > Regards > Felix >
