Hi
Am 13.11.2013 um 23:12 schrieb Felix Meschberger <[email protected]>: > Hi Bertrand > > Thanks. This looks like a promising start. > > I have some comments, though ;-) > > 1. My first reaction to the SlingHttpServletRequest argument was: Why an > argument ? Why not a ThreadLocal managed by the actual service with the help > of a request filter ? (ok, what to do with non-request services). > > 2. I think the Providers should just register their known feature names as > string-service properties. Could there be more than one supported feature > actually ? Or is it really just a single one ? When using a service > registration property we can start with single-string and switch to > multi-value later without changing the API. > > 3. Configuration: This is a good point brought up by Dominik: We want to have > central/singular configuration for the feature flags not spread them amongst > tons of providers. And we have configuration which is global (static) and we > have configuration which is per-user/group/time-of-day/random/whatever. > > 4. Thinking about it: these providers actually just evaluate an expression > based on some configuration and some comparison object. Maybe there is a > better term than „Provider“ for these things. > > 5. I understand FeatureFlags is actually the service we are interested in: > - How about calling that just Feature with then call > „Feature.isEnabled(FeatureX)“ then ? > - We should expose the Feature Service in the SlingBindings > - We should expose the Feature Service in the sling:defineObjects tag > - we should probably expose the Feature Service in some sling:feature JSP > tag > > 6. Re. Enums: On first sight this looks like a good idea. But it has the > drawback that it generates a package wiring dependency and requires the ENUMs > to be exported as API. What is the worst case szenarion of mis-typing a > feature ? I think, the feature will just never be enabled. (ok, another one > is that another unrelated feature might be enabled due to the typo — which > could be mitigated by stipulating features to have reasonably distinct names). I forgot 7. FeatureFlagsProvider (or however it will be called) should just return boolean (scalar) not a wrapper. If the provider is called with an unsupported/unknown feature, it should just return false. This makes the code simpler, I think. Regards Felix > > Regards > Felix > > — > Felix Meschberger | Principal Scientist | Adobe > > > > Am 13.11.2013 um 02:52 schrieb Bertrand Delacretaz <[email protected]>: > >> Hi, >> >> FYI I have created a minimal prototype [2] of how I'd see feature >> flags in Sling, as suggested a while ago by Henry Saginor in >> SLING-3148. >> >> The slides at [1], that Tommaso tweeted today, are full of good ideas >> about this. >> >> -Bertrand >> >> [1] http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf >> >> [2] >> https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/feature-flags >
