On 30.10.2012, at 08:43, Mike Müller wrote:
>>> And it's totally transparent and doesn't need any changes to the core.
>>
>> Depends on what you define as "core". The proposal definitely mentions a
>> change to
>> the resource resolver core.
>
> No existing API will be changed. The changes are
2012/10/30 Ian Boston :
> what about being able to check for a set of permissions in one go ?
As far as the proposal goes, there is no need for this as usually
always exactly one permission is checked.
Carsten
>
>>
>> So I would go with the separate methods - we could provide an abstract
>> clas
2012/10/30 Bertrand Delacretaz :
>> ...I also don't see a need to do it in the same way as JCR does - we
>> should do it what fits best in our resource api and what is the best
>> way to cover the use cases :)...
>
> Of course, but some consistency wouldn't hurt either, I don't see what
> makes th
On Tue, Oct 30, 2012 at 10:59 AM, Carsten Ziegeler wrote:
> ...I'm not sure about checkPermission with a String (or String[]). This
> would imho only make sense if we see that we will have more
> permissions in the future which I really don't see...
Thinking that no new types of permissions will
On 30 October 2012 20:59, Carsten Ziegeler wrote:
> I'm not sure about checkPermission with a String (or String[]). This
> would imho only make sense if we see that we will have more
> permissions in the future which I really don't see. And we don't need
> an extension here as each additional perm
I'm not sure about checkPermission with a String (or String[]). This
would imho only make sense if we see that we will have more
permissions in the future which I really don't see. And we don't need
an extension here as each additional permission would require changes
in the implementation to check
On 30 October 2012 20:18, Bertrand Delacretaz wrote:
> Hi,
>
> On Fri, Oct 26, 2012 at 10:43 AM, Mike Müller wrote:
>> ...The main goal of this proposal is to provide a easy to use service in
>> Sling to restrict (or grant) access to resources for special use cases
>> (like giving access to some
Hi,
On Fri, Oct 26, 2012 at 10:43 AM, Mike Müller wrote:
> ...The main goal of this proposal is to provide a easy to use service in
> Sling to restrict (or grant) access to resources for special use cases
> (like giving access to some resources only between 8am and 5pm). The
> service should be v
> > And it's totally transparent and doesn't need any changes to the core.
>
> Depends on what you define as "core". The proposal definitely mentions a
> change to
> the resource resolver core.
No existing API will be changed. The changes are only "under the hood". These
changes
only come to "l
2012/10/29 Alexander Klimetschek :
> On 29.10.2012, at 18:02, Carsten Ziegeler wrote:
>
>> And it's totally transparent and doesn't need any changes to the core.
>
> Depends on what you define as "core". The proposal definitely mentions a
> change to the resource resolver core.
No, the resource
On 29.10.2012, at 18:02, Carsten Ziegeler wrote:
> And it's totally transparent and doesn't need any changes to the core.
Depends on what you define as "core". The proposal definitely mentions a change
to the resource resolver core.
On 26.10.2012, at 10:43, Mike Müller wrote:
> Okay, how sho
I like this proposal as it is really generic and allows for some very
interesting use cases like denying access to resources for a given
time or allowing only access if the user has paid for the content or
whatever :)
And it's totally transparent and doesn't need any changes to the core.
As we're
On 26.10.2012, at 10:43, Mike Müller wrote:
> The main goal of this proposal is to provide a easy to use service in
> Sling to restrict (or grant) access to resources for special use cases
> (like giving access to some resources only between 8am and 5pm). The
> service should be very lightweight
13 matches
Mail list logo
