This is what I derive from your Roy's comments. It is not possible to predict all of the changes that might be conditioned via a flag. The context is really up to the application developers and their requirements. Applying feature flags at the resource level would only cover a particular set of changes. So, fundamentally all that the framework can do is provide a way to define flags, provide a switch panel and a way to extend it, and API to check flags in condition statements. How and where each flag is used is up to the developer of a specific application feature.
Also, API for flag checking needs to be made available on both client and server without them calling each other. This can get tricky when we consider caching. On Nov 15, 2013, at 6:00 PM, "Roy T. Fielding" <field...@gbiv.com> wrote: > On Nov 15, 2013, at 2:54 PM, Alexander Klimetschek wrote: >> On 15.11.2013, at 07:13, Amit.. Gupta. <amitg...@adobe.com> wrote: >> >>> 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. >> >> Ack. IMO feature flags are clearly a high-level application, not >> infrastructure, aspect. > > Feature flags are a mechanism for isolating changes within a deployed > system. Any part of that system. > > That means a feature flag needs to be able to condition any change > that might be made to a system, including any change to the configuration > files/data, any change to code monitoring the system, any change to the > selection of data sources, any change to content (including everything > as content), any change to a layout within any page or component, any > change to the order in which things are done, any change to a report > about what was done, and any change I haven't mentioned yet short of > physically walking up to the server rack and unplugging the power > by hand. > > In short, if it is content, it can be made conditional on the basis > of a feature flag. That is the granularity of feature flag use. > > Separate from that is the feature flag flip switch (i.e., the set > of ways that a given feature can be turned on) and the extent to > which a feature becomes sticky per user once enabled for that user. > > You should expect a typical deployed site to have on the order of > 1024 active feature flags. Hence, think carefully before choosing > a verbose (or linear) mechanism for checking or remembering flags. > Likewise, you should expect to have both a global setting for each > flag and a per-user mask, and the person running the flip switch > control panel needs to be able to choose from > > a) off for all users > b) off for unassigned users > c) proportional assignment to on (X out of N users, max M) > d) logical (custom code) assignment to on > e) on for unassigned users > f) on for all users > > and be able to remember assignments per user, without requiring > the user to login, and without assigning more than one cookie. > > Oh, and a flag check should be available for both server-side > and client-side code, without calling the other side. > > Finally, for the ultimate effect, it ought to be possible to burn > a flag by automating the removal of all conditionals within managed > content that require that flag (change the content to permanently on) > or the removal of all such conditions (permanently off). > > Cheers, > > ....Roy >
