Hi Henry, the way understand Feature Flags as well as the comment from Roy is quite different: - Features can be content, java code, configuration or anything else that you would touch to introduce a new feature - Therefore the when a feature is turned off ist must be granted that (as far as technically possible) the feature has no impact on the behavior of the system (this might not be achivable since the only way of total removal of impact is not to release it, but the goal is to get as close as possible to this state) - Pure highlevel application checks cannot accomplish this since the plattform API would anyway call different logic and has to rely on the high level API to produce the same result (e.g. the resolutionprocess would be different between (a) the feature not being present at all (since there is no resource found) (b) the feature is disabled and a third logic (like a filter) needs to take care of this.
I read Roy's comment that this is something required, but there is even more than that, like configuration which needs to be taken into account. But when looking at the area of resource resolving filtering the resourcetree in first place is as close as we can get to a similar behavior like non-existance. Best regards Dominik P.S. Isolation of JS logic isn't that hard, you just make sure that all plugins of a feature are included as one JS file. The hard part is request optimization where you might want to aggregate the plugins. This might be achivable by aggregations that have generated featurehashes in their URL (this way all users consuming the same featureset get the same aggregation so you still can cache). On Mon, Nov 18, 2013 at 11:43 PM, Henry Saginor <hsagi...@gmail.com> wrote: > 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 > > > >
