You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2016/08/01 10:37:26 UTC
Re: Sling Oak Restrictions - Release 1.0.0 now?
Hi Georg,
On Sat, 2016-07-30 at 10:14 +0200, Georg Henzler wrote:
> Hi all,
>
> with SLING-5768/SLING-5891 fixed and the documentation in�
> https://sling.apache.org/documentation/bundles/sling-oak-restrictions
> .html�
> we have everything needed to cut a first release IMHO - could
> someone�
> take care of it?
I think we need to clarify two issues:
1. Bundle name and location
Right now the Bundle-SymbolicName is�org.apache.sling.sling-oak-
restrictions and it's placed under contrib/extensions . I would rather
see it named org.apache.sling.jcr.oak-restrictions and placed under
contrib/jcr .
2. Naming of the restrictions
There was some discussion related to the name of the
'sling:resourceTypesWithChildren' restriction [1]. I want to make sure
that we have agreement that this is the best name what we could come up
with before releasing and committing to this name "forever".
Once these are agreed on, I can take care of an initial release.
Robert
[1]:�https://issues.apache.org/jira/browse/SLING-5768
Re: Sling Oak Restrictions - Release 1.0.0 now?
Posted by Georg Henzler <sl...@ghenzler.de>.
Hi,
this makes sense, so I updated SLING-6045 and created a PR [1]. If
everyone is happy with this version, maybe we can merge and create a
first release?
Regards
Georg
[1]
https://github.com/apache/sling/pull/173
On 2016-09-09 15:08, Konrad Windszus wrote:
> I am also in favour of putting it in contrib/extensions and name the
> package/artifact id org.apache.sling.oak.restriction.
> Konrad
>
>> Am 08.09.2016 um 22:32 schrieb Oliver Lietz <ap...@oliverlietz.de>:
>>
>> On Thursday 08 September 2016 17:48:24 Georg Henzler wrote:
>>> Hi Oliver,
>>
>> Hi Georg,
>>
>>> if we call it "oak", we probably would have to also create a sub
>>> folder
>>> contrib/oak (as all modules in contrib/jcr have the group id
>>> org.apache.sling.jcr)... that's probably more confusing than just
>>> leaving it in contrib/jcr (having jcr and oak side by side when oak
>>> also
>>> provides the jcr). Robert, what do you think?
>>
>> I'm fine with it in contrib/extensions and moving it around in SVN is
>> not a
>> problem in contrast to changing packages later.
>>
>> Regards,
>> O.
>>
>>> Regards
>>> Georg
>> [...]
>>
Re: Sling Oak Restrictions - Release 1.0.0 now?
Posted by Konrad Windszus <ko...@gmx.de>.
I am also in favour of putting it in contrib/extensions and name the package/artifact id org.apache.sling.oak.restriction.
Konrad
> Am 08.09.2016 um 22:32 schrieb Oliver Lietz <ap...@oliverlietz.de>:
>
> On Thursday 08 September 2016 17:48:24 Georg Henzler wrote:
>> Hi Oliver,
>
> Hi Georg,
>
>> if we call it "oak", we probably would have to also create a sub folder
>> contrib/oak (as all modules in contrib/jcr have the group id
>> org.apache.sling.jcr)... that's probably more confusing than just
>> leaving it in contrib/jcr (having jcr and oak side by side when oak also
>> provides the jcr). Robert, what do you think?
>
> I'm fine with it in contrib/extensions and moving it around in SVN is not a
> problem in contrast to changing packages later.
>
> Regards,
> O.
>
>> Regards
>> Georg
> [...]
>
Re: Sling Oak Restrictions - Release 1.0.0 now?
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Thursday 08 September 2016 17:48:24 Georg Henzler wrote:
> Hi Oliver,
Hi Georg,
> if we call it "oak", we probably would have to also create a sub folder
> contrib/oak (as all modules in contrib/jcr have the group id
> org.apache.sling.jcr)... that's probably more confusing than just
> leaving it in contrib/jcr (having jcr and oak side by side when oak also
> provides the jcr). Robert, what do you think?
I'm fine with it in contrib/extensions and moving it around in SVN is not a
problem in contrast to changing packages later.
Regards,
O.
> Regards
> Georg
[...]
Re: Sling Oak Restrictions - Release 1.0.0 now?
Posted by Georg Henzler <sl...@ghenzler.de>.
Hi Oliver,
if we call it "oak", we probably would have to also create a sub folder
contrib/oak (as all modules in contrib/jcr have the group id
org.apache.sling.jcr)... that's probably more confusing than just
leaving it in contrib/jcr (having jcr and oak side by side when oak also
provides the jcr). Robert, what do you think?
Regards
Georg
On 2016-09-07 22:33, Oliver Lietz wrote:
> On Monday 01 August 2016 13:37:26 Robert Munteanu wrote:
>> Hi Georg,
>
> Hi,
>
>> On Sat, 2016-07-30 at 10:14 +0200, Georg Henzler wrote:
>> > Hi all,
>> >
>> > with SLING-5768/SLING-5891 fixed and the documentation in
>> > https://sling.apache.org/documentation/bundles/sling-oak-restrictions
>> > .html
>> > we have everything needed to cut a first release IMHO - could
>> > someone
>> > take care of it?
>>
>> I think we need to clarify two issues:
>>
>> 1. Bundle name and location
>>
>> Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
>> restrictions and it's placed under contrib/extensions . I would rather
>> see it named org.apache.sling.jcr.oak-restrictions and placed under
>> contrib/jcr .
>
> the bundle is not using JCR API but Oak API only
> (org.apache.jackrabbit.oak.spi.security.authorization.restriction).
> Shouldn't
> we go for a simple module and package name
> org.apache.sling.oak.restriction?
>
> Regards,
> O.
>
>> 2. Naming of the restrictions
>>
>> There was some discussion related to the name of the
>> 'sling:resourceTypesWithChildren' restriction [1]. I want to make sure
>> that we have agreement that this is the best name what we could come
>> up
>> with before releasing and committing to this name "forever".
>>
>> Once these are agreed on, I can take care of an initial release.
>>
>> Robert
>>
>> [1]: https://issues.apache.org/jira/browse/SLING-5768
Re: Sling Oak Restrictions - Release 1.0.0 now?
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Monday 01 August 2016 13:37:26 Robert Munteanu wrote:
> Hi Georg,
Hi,
> On Sat, 2016-07-30 at 10:14 +0200, Georg Henzler wrote:
> > Hi all,
> >
> > with SLING-5768/SLING-5891 fixed and the documentation in
> > https://sling.apache.org/documentation/bundles/sling-oak-restrictions
> > .html
> > we have everything needed to cut a first release IMHO - could
> > someone
> > take care of it?
>
> I think we need to clarify two issues:
>
> 1. Bundle name and location
>
> Right now the Bundle-SymbolicName is org.apache.sling.sling-oak-
> restrictions and it's placed under contrib/extensions . I would rather
> see it named org.apache.sling.jcr.oak-restrictions and placed under
> contrib/jcr .
the bundle is not using JCR API but Oak API only
(org.apache.jackrabbit.oak.spi.security.authorization.restriction). Shouldn't
we go for a simple module and package name org.apache.sling.oak.restriction?
Regards,
O.
> 2. Naming of the restrictions
>
> There was some discussion related to the name of the
> 'sling:resourceTypesWithChildren' restriction [1]. I want to make sure
> that we have agreement that this is the best name what we could come up
> with before releasing and committing to this name "forever".
>
> Once these are agreed on, I can take care of an initial release.
>
> Robert
>
> [1]: https://issues.apache.org/jira/browse/SLING-5768
Re: Sling Oak Restrictions - Release 1.0.0 now?
Posted by Georg Henzler <sl...@ghenzler.de>.
Hi Robert,
thanks for merging SLING-6042. For your comment regarding the better
location contrib/jcr I created SLING-6045 including a PR. So if everyone
is happy with this version then, it would be great to have a first
release!
Regards
Georg
On 2016-08-01 12:37, Robert Munteanu wrote:
>
> 1. Bundle name and location
>
> Right now the Bundle-SymbolicName is�org.apache.sling.sling-oak-
> restrictions and it's placed under contrib/extensions . I would rather
> see it named org.apache.sling.jcr.oak-restrictions and placed under
> contrib/jcr .
>
Re: Sling Oak Restrictions - Release 1.0.0 now?
Posted by Georg Henzler <sl...@ghenzler.de>.
On 2016-08-02 09:41, Konrad Windszus wrote:
>> I think sling:resourceTypesWithChildren is the clearest suggestion up
>> to now ([1] gives an example). From a pure user point of view, the
>> terms "parent" or "ancestry" would be rather misleading, because what
>> is matched by the restriction in the end are nodes below (and not
>> above) the matched node with the given resource type, e.g. the
>> restriction matches a node with resource type "myproj/news" with (or
>> including) all children.
> For me the matched node is the one I want to modify/insert, not the
> one carrying the ACE with the restriction.
correct - the node carrying the ACE is the upper boundary of possible
matches (this is oak standard for all restrictions and does not really
have to be repeated)
> Maybe we should clarify
> that even more in the documentation, because when it comes to applying
> ACEs you are dealing with two different nodes: the one you try to
> modify and the one where the ACE is set (this is not necessarily the
> same node).
We have "Naturally (as with any oak restrictions), the rule is limited
to its base path. In case the node /content/myprj/othernode is of
resource type myproj/comp1, it will still not match." in the
documenation, but I'm sure it can be improved...
> For me the documentation at [1] is not clear enough in
> that regard, especially how inheritance is being treated. On which
> level is the resourceType being compared? On the level where the ACE
> is set or on the matched node level?
Like for all oak restrictions, any ACE is only applied if all given
restrictions apply. sling:resourceTypesWithChildren (or probably better
sling:resourceTypesWithDescendants) will be clever and also match
descendants, even if it is not a direct match of a particular node.
@Konrad regarding the naming, which one of the following would you
prefer?
- sling:resourceTypesDeep <-- less descriptive but also shorter
- sling:resourceTypesWithDescendants <-- I think clearer, but longer
Regards
Georg
Re: Sling Oak Restrictions - Release 1.0.0 now?
Posted by Konrad Windszus <ko...@gmx.de>.
> On 01 Aug 2016, at 13:32, Georg Henzler <sl...@ghenzler.de> wrote:
>
> Hi Robert,
>
>> ... I would rather see it named org.apache.sling.jcr.oak-restrictions
>> and placed under contrib/jcr .
>
> That sounds like a better location, +1 to move
>
>> There was some discussion related to the name of the
>> 'sling:resourceTypesWithChildren' restriction [1]. I want to make sure
>> that we have agreement that this is the best name
>
> I think sling:resourceTypesWithChildren is the clearest suggestion up to now ([1] gives an example). From a pure user point of view, the terms "parent" or "ancestry" would be rather misleading, because what is matched by the restriction in the end are nodes below (and not above) the matched node with the given resource type, e.g. the restriction matches a node with resource type "myproj/news" with (or including) all children.
For me the matched node is the one I want to modify/insert, not the one carrying the ACE with the restriction. Maybe we should clarify that even more in the documentation, because when it comes to applying ACEs you are dealing with two different nodes: the one you try to modify and the one where the ACE is set (this is not necessarily the same node). For me the documentation at [1] is not clear enough in that regard, especially how inheritance is being treated. On which level is the resourceType being compared? On the level where the ACE is set or on the matched node level?
Also the sentence: "Only resources that have one of the supplied resource types are matched, child and parent resources with other resource types are not matched."
What node does parent and child refer to in this sentence?
>
> Regards
> Georg
>
>
> [1]
> https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html#restriction-slingresourcetypeswithchildren
Re: Sling Oak Restrictions - Release 1.0.0 now?
Posted by Georg Henzler <sl...@ghenzler.de>.
Hi Robert,
I updated SLING-5768 and SLING-5890 (markdown docu) for using
sling:resourceTypesWithDescendants. If everyone is reasonably happy with
it, I think we should just go with that :)
Regards
Georg
On 2016-08-01 13:56, Georg Henzler wrote:
> Hi Julian,
>
> good point that "descendants" is actually clearer than "children"...
> that gives two options IMHO:
>
> - sling:resourceTypesDeep <-- less descriptive but also shorter
> - sling:resourceTypesWithDescendants <-- I think clearer, but longer
>
> For the simple match, I would stick with the short name
> sling:resourceTypes
> as it is more in line with the standard oak restrictions.
>
> Regards
> Georg
>
> On 2016-08-01 13:48, Julian Sedding wrote:
>> Hi Georg
>>
>> I think "...WithChildren" is misleading, because, per my understanding
>> of the documentation, it means "with descendants".
>>
>> Maybe restriction names with "shallow" and/or "deep" would be more
>> self-documenting?
>>
>> E.g. "sling:resourceTypesShallow" and "sling:resourceTypesDeep".
>>
>> WDYT?
>>
>> Regards
>> Julian
>>
>>
>> On Mon, Aug 1, 2016 at 1:32 PM, Georg Henzler <sl...@ghenzler.de>
>> wrote:
>>> Hi Robert,
>>>
>>>> ... I would rather see it named
>>>> org.apache.sling.jcr.oak-restrictions
>>>> and placed under contrib/jcr .
>>>
>>>
>>> That sounds like a better location, +1 to move
>>>
>>>> There was some discussion related to the name of the
>>>> 'sling:resourceTypesWithChildren' restriction [1]. I want to make
>>>> sure
>>>> that we have agreement that this is the best name
>>>
>>>
>>> I think sling:resourceTypesWithChildren is the clearest suggestion up
>>> to now
>>> ([1] gives an example). From a pure user point of view, the terms
>>> "parent"
>>> or "ancestry" would be rather misleading, because what is matched by
>>> the
>>> restriction in the end are nodes below (and not above) the matched
>>> node with
>>> the given resource type, e.g. the restriction matches a node with
>>> resource
>>> type "myproj/news" with (or including) all children.
>>>
>>> Regards
>>> Georg
>>>
>>>
>>> [1]
>>> https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html#restriction-slingresourcetypeswithchildren
Re: Sling Oak Restrictions - Release 1.0.0 now?
Posted by Georg Henzler <sl...@ghenzler.de>.
Hi Julian,
good point that "descendants" is actually clearer than "children"...
that gives two options IMHO:
- sling:resourceTypesDeep <-- less descriptive but also shorter
- sling:resourceTypesWithDescendants <-- I think clearer, but longer
For the simple match, I would stick with the short name
sling:resourceTypes
as it is more in line with the standard oak restrictions.
Regards
Georg
On 2016-08-01 13:48, Julian Sedding wrote:
> Hi Georg
>
> I think "...WithChildren" is misleading, because, per my understanding
> of the documentation, it means "with descendants".
>
> Maybe restriction names with "shallow" and/or "deep" would be more
> self-documenting?
>
> E.g. "sling:resourceTypesShallow" and "sling:resourceTypesDeep".
>
> WDYT?
>
> Regards
> Julian
>
>
> On Mon, Aug 1, 2016 at 1:32 PM, Georg Henzler <sl...@ghenzler.de>
> wrote:
>> Hi Robert,
>>
>>> ... I would rather see it named org.apache.sling.jcr.oak-restrictions
>>> and placed under contrib/jcr .
>>
>>
>> That sounds like a better location, +1 to move
>>
>>> There was some discussion related to the name of the
>>> 'sling:resourceTypesWithChildren' restriction [1]. I want to make
>>> sure
>>> that we have agreement that this is the best name
>>
>>
>> I think sling:resourceTypesWithChildren is the clearest suggestion up
>> to now
>> ([1] gives an example). From a pure user point of view, the terms
>> "parent"
>> or "ancestry" would be rather misleading, because what is matched by
>> the
>> restriction in the end are nodes below (and not above) the matched
>> node with
>> the given resource type, e.g. the restriction matches a node with
>> resource
>> type "myproj/news" with (or including) all children.
>>
>> Regards
>> Georg
>>
>>
>> [1]
>> https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html#restriction-slingresourcetypeswithchildren
Re: Sling Oak Restrictions - Release 1.0.0 now?
Posted by Julian Sedding <js...@gmail.com>.
Hi Georg
I think "...WithChildren" is misleading, because, per my understanding
of the documentation, it means "with descendants".
Maybe restriction names with "shallow" and/or "deep" would be more
self-documenting?
E.g. "sling:resourceTypesShallow" and "sling:resourceTypesDeep".
WDYT?
Regards
Julian
On Mon, Aug 1, 2016 at 1:32 PM, Georg Henzler <sl...@ghenzler.de> wrote:
> Hi Robert,
>
>> ... I would rather see it named org.apache.sling.jcr.oak-restrictions
>> and placed under contrib/jcr .
>
>
> That sounds like a better location, +1 to move
>
>> There was some discussion related to the name of the
>> 'sling:resourceTypesWithChildren' restriction [1]. I want to make sure
>> that we have agreement that this is the best name
>
>
> I think sling:resourceTypesWithChildren is the clearest suggestion up to now
> ([1] gives an example). From a pure user point of view, the terms "parent"
> or "ancestry" would be rather misleading, because what is matched by the
> restriction in the end are nodes below (and not above) the matched node with
> the given resource type, e.g. the restriction matches a node with resource
> type "myproj/news" with (or including) all children.
>
> Regards
> Georg
>
>
> [1]
> https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html#restriction-slingresourcetypeswithchildren
Re: Sling Oak Restrictions - Release 1.0.0 now?
Posted by Georg Henzler <sl...@ghenzler.de>.
Hi Robert,
> ... I would rather see it named org.apache.sling.jcr.oak-restrictions
> and placed under contrib/jcr .
That sounds like a better location, +1 to move
> There was some discussion related to the name of the
> 'sling:resourceTypesWithChildren' restriction [1]. I want to make sure
> that we have agreement that this is the best name
I think sling:resourceTypesWithChildren is the clearest suggestion up to
now ([1] gives an example). From a pure user point of view, the terms
"parent" or "ancestry" would be rather misleading, because what is
matched by the restriction in the end are nodes below (and not above)
the matched node with the given resource type, e.g. the restriction
matches a node with resource type "myproj/news" with (or including) all
children.
Regards
Georg
[1]
https://sling.apache.org/documentation/bundles/sling-oak-restrictions.html#restriction-slingresourcetypeswithchildren