On 12.12.2013, at 19:40, Carsten Ziegeler wrote:
> I think you missunderstood me, or we're maybe talking about different
> things - as repeatedly stated we don't need to change the resource resolver
> - we have everything in place; and now we exactly need to define the use
> cases to know how the
I think you missunderstood me, or we're maybe talking about different
things - as repeatedly stated we don't need to change the resource resolver
- we have everything in place; and now we exactly need to define the use
cases to know how the flags api should look like and which possibilites it
has.
On 11.12.2013, at 19:10, Carsten Ziegeler wrote:
> I think we're pretty clear now how we could implement this, basically
> everything is in place, so the resource resolver has all features we need
> in the way we need them. And we should now start defining the feature flags
> api.
Did you read m
I think we're pretty clear now how we could implement this, basically
everything is in place, so the resource resolver has all features we need
in the way we need them. And we should now start defining the feature flags
api.
Carsten
2013/12/12 Alexander Klimetschek
> From: Felix Meschberger
>
From: Felix Meschberger
> For "hiding" resources I would really prefer hooking into the
> ResourceResolverImpl and make that be
> aware of FeatureFlags itself. (I seem to repeat myself here, but I seem to
> have a strong position on
> that :-) )
The problem of integrating that right into the r
On Wed, Dec 11, 2013 at 10:00 AM, Carsten Ziegeler wrote:
> 2013/12/11 Bertrand Delacretaz
>>... Maybe a ResourceAccessVeto service, with a single vetoResourceAccess()
>> method?
>>
> Yepp, thanks that was actually my initial idea (though I didn't bring it
> across...) - we define this extra serv
2013/12/11 Bertrand Delacretaz
> Hi,
>
> On Wed, Dec 11, 2013 at 9:34 AM, Felix Meschberger
> wrote:
> > ...For "hiding" resources I would really prefer hooking into the
> ResourceResolverImpl and make that
> > be aware of FeatureFlags itself. (I seem to repeat myself here, but I
> seem to have
:) Ok, but the resource access stuff is deep in the resource resolver
already and provides the exact functionality we need: hiding a resource
under some conditions - so why adding a second implementation, doubling the
complexity in this area just with the same functionality?
Of course the service w
Hi,
On Wed, Dec 11, 2013 at 9:34 AM, Felix Meschberger wrote:
> ...For "hiding" resources I would really prefer hooking into the
> ResourceResolverImpl and make that
> be aware of FeatureFlags itself. (I seem to repeat myself here, but I seem to
> have a strong
> position on that :-) )...
I re
Hi
I disagree ;-)
For "hiding" resources I would really prefer hooking into the
ResourceResolverImpl and make that be aware of FeatureFlags itself. (I seem to
repeat myself here, but I seem to have a strong position on that :-) )
As for changing the rendering, I would assume you primarily mean
So can we agree to continue with these two appraches:
- global ResourceAccessSecurity for hidding resources
- Decorator for changing rendering
?
Carsten
2013/12/11 Bertrand Delacretaz
> On Tue, Dec 10, 2013 at 1:01 PM, Carsten Ziegeler
> wrote:
> > ...it pays back that we had strong oponents
On Tue, Dec 10, 2013 at 1:01 PM, Carsten Ziegeler wrote:
> ...it pays back that we had strong oponents of simply calling the
> ResourceAccessGate for every provider...
If needed we could differentiate between global and per-provider
ResourceAccessGates using service properties.
-Bertrand
On Tue, Dec 10, 2013 at 1:01 PM, Carsten Ziegeler wrote:
> ...For alternate rendering we can use a resource decorator - instead of using
> different scripts for the same resource type, the decorator returns a
> resource which has a different resource type. This would require zero
> changes to the
Yes, now it pays back that we had strong oponents of simply calling the
ResourceAccessGate for every provider... :(
But we can reconsider this and are done.
For alternate rendering we can use a resource decorator - instead of using
different scripts for the same resource type, the decorator return
Hi
Am 10.12.2013 um 12:04 schrieb Bertrand Delacretaz :
> On Tue, Dec 10, 2013 at 11:45 AM, Carsten Ziegeler
> wrote:
>> ...I think it has been mentioned as well, ResourceAccessGate does exactly
>> what
>> is needed for handling frags on resources - it filters and allows to return
>> null (den
On Tue, Dec 10, 2013 at 11:45 AM, Carsten Ziegeler wrote:
> ...I think it has been mentioned as well, ResourceAccessGate does exactly what
> is needed for handling frags on resources - it filters and allows to return
> null (deny access) based on some implementation. So why aren't we using
> this?
I've been thinking about this a little bit, and as has been said
ResourceDecorator is not the solution as this does not allow to hide a
resource - we can't change this contract and I now implementations of the
decorator relying on this.
I think it has been mentioned as well, ResourceAccessGate doe
Hi,
On Mon, Dec 9, 2013 at 11:01 PM, Carsten Ziegeler wrote:
> ...do we have a wiki page where we collect real use cases for
> feature flags?...
I've just created
https://cwiki.apache.org/confluence/display/SLING/Sling+Feature+Flags+support
for that.
(don't expect too much...It just says "TBD"
Good idea - do we have a wiki page where we collect real use cases for
feature flags?
Carsten
2013/12/10 Bertrand Delacretaz
> Hi,
>
> On Sun, Dec 8, 2013 at 6:04 AM, Carsten Ziegeler
> wrote:
> > ...I can see how we can implement a global feature flag within the
> resource
> > resolver easil
Hi,
On Sun, Dec 8, 2013 at 6:04 AM, Carsten Ziegeler wrote:
> ...I can see how we can implement a global feature flag within the resource
> resolver easily, but as soon as there is some "randomness" involved, like
> enable it for specific users or N users etc. this really gets tricky
I agree
I can see how we can implement a global feature flag within the resource
resolver easily, but as soon as there is some "randomness" involved, like
enable it for specific users or N users etc. this really gets tricky.
Script resolution would be at least one area causing troubles.
As Ruben points out
it may be worth it revisiting the tenant api in regards to feature flags
as well and have some sort of way to have feature flag dependent osgi
properties.
Ruben
On 12/6/2013 12:51 PM, Justin Edelson wrote:
On Fri, Dec 6, 2013 at 12:10 PM, Alexander Klimetschek
wrote:
On 06.12.2013, at 08:08
On Fri, Dec 6, 2013 at 12:10 PM, Alexander Klimetschek
wrote:
> On 06.12.2013, at 08:08, Felix Meschberger wrote:
>
>> Think back and forth I really think that we should put feature flag support
>> into the ResourceResolver proper.
>
> I agree.
+1
Henry wrote it well: "So, fundamentally all t
On 06.12.2013, at 08:08, Felix Meschberger wrote:
> Think back and forth I really think that we should put feature flag support
> into the ResourceResolver proper.
I agree.
Another completely open question is: the resource resolver is not tied to a
request, backend services use it as well. S
corated but not vice versa).
best regards
mike
> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Friday, December 06, 2013 11:49 AM
> To: dev
> Subject: Re: [OT] Feature flag influence on Resource access (Was: FYI: feature
> flags p
Hi
Please don't mingle resource decoration with the feature flag. The use cases
are different and returning null from the ResourceDecorator is clearly defined
to be same as returning the same resource, i.e. no decoration at all. If this
results in NPEs the calling code must be fixed.
Feature f
Hi,
On Fri, Nov 15, 2013 at 8:40 AM, Felix Meschberger 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...
I had anot
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 techn
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
On Nov 15, 2013, at 2:54 PM, Alexander Klimetschek wrote:
> On 15.11.2013, at 07:13, Amit.. Gupta. 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
On 15.11.2013, at 07:13, Amit.. Gupta. 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 th
mit
>
> -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:
On Fri, Nov 15, 2013 at 2:23 PM, Felix Meschberger wrote:
> ...If you know, though, that the resource exists and is guarded by a feature
> flag,
> you can still make sure to temporarily enable the feature in your current
> context to remove the flag
Yes, the idea is to support any way of ena
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 Featur
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 Feature
t filter as Alex suggested.
I am not in favor of having restricted implementations because this tends to
result in inconsistent behaviour.
Regards
Felix
>
> Thanks,
> Amit
>
> -Original Message-
> From: Felix Meschberger [mailto:fmesc...@adobe.com]
> Sent: 15 November
vlet 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 pro
it
-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 cur
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 resou
39 matches
Mail list logo
