RootImpl to AbstractRoot

[Antonio Sanso <as...@adobe.com>]

hi *,

during a conversation with Angela yesterday came out that it might be to change RootImpl to be abstract (e.g. AbstractRoot) making also

    public abstract ContentSession getContentSession();

this will also make more visible the need of implement the getContentSession method.
In the oak-core RootImpl is used twice AFAIK and both time it override this method in a different way.

WDYT?

regards

antonio

Re: RootImpl to AbstractRoot

[Michael Dürig <md...@apache.org>]

On 25.7.13 15:27, Antonio Sanso wrote:
> I have the impression that the name ImmutableTree/Root doesn't match completely the concept.
>
> A more appropriate name would be IMHO something like ImmutableUnsecureTree/Root
>
> We might also have ImmutableTree/Root though but then will have some security layer as the Mutable one.
> This change of name might allow us to be more specific on some internal API where we currently pass a Tree but what we actually would need is ImmutableUnsecureTree

It seems to me we are mixing different aspects here: the one of 
mutability and the one of access rights. AFAICS it happens to be the 
case that for the permission evaluation code immutable trees are 
sufficient but we need them also to be non secured.

Lets go one step at a time. First refactor the commonalities of the 
respective Root implementations into a common base class and rename the 
sub classes to much those of Tree.

Second we might want to have another look on the separation of secured 
vs. non secured trees and how we could better handle this.

Michael

Re: RootImpl to AbstractRoot

[Angela Schreiber <an...@adobe.com>]

hi antonio

ImmutableInsecureTree? that sounds scary :-)

there is nothing insecure about this those trees, they are
just not checked for read-access. in other words omit any kind
of access control / permission check. and consequently the
MutableTree would need to be called MutablePermissionControlledTree.

i would stick with the names or look for something completely
different. as long as the javadoc stresses the nature of those
implementations i am fine.

what we should do however is removing the core package
from the osgi export. the classes contained therein are
internal implementation and should not be used outside of
the oak-core implementation and plugins... so we might consider
refactoring that part of the code a bit and carefully decide
which parts of oak-core should really be made public.

kind regards
angela

On 7/25/13 3:27 PM, "Antonio Sanso" <as...@adobe.com> wrote:

>thanks michael,
>
>I have started an implementation of what you have suggested.
>
>I have the impression that the name ImmutableTree/Root doesn't match
>completely the concept.
>
>A more appropriate name would be IMHO something like
>ImmutableUnsecureTree/Root
>
>We might also have ImmutableTree/Root though but then will have some
>security layer as the Mutable one.
>This change of name might allow us to be more specific on some internal
>API where we currently pass a Tree but what we actually would need is
>ImmutableUnsecureTree
>
>just my 0.02 $ :)
>
>Regards
>
>Antonio
>
>On Jul 24, 2013, at 11:57 AM, Michael Dürig wrote:
>
>> 
>> 
>> On 24.7.13 11:52, Antonio Sanso wrote:
>>> during a conversation with Angela yesterday came out that it might be
>>>to change RootImpl to be abstract (e.g. AbstractRoot) making also
>> 
>> Makes sense given there are enough commonalities to share. Have a look
>> at MutableTree, ImmutableTree and its common ancestor AbstractTree. I
>> think we should follow this pattern for Root.
>> 
>> Michael
>

Re: RootImpl to AbstractRoot

[Antonio Sanso <as...@adobe.com>]

thanks michael,

I have started an implementation of what you have suggested.

I have the impression that the name ImmutableTree/Root doesn't match completely the concept.

A more appropriate name would be IMHO something like ImmutableUnsecureTree/Root

We might also have ImmutableTree/Root though but then will have some security layer as the Mutable one.
This change of name might allow us to be more specific on some internal API where we currently pass a Tree but what we actually would need is ImmutableUnsecureTree

just my 0.02 $ :)

Regards

Antonio

On Jul 24, 2013, at 11:57 AM, Michael Dürig wrote:

> 
> 
> On 24.7.13 11:52, Antonio Sanso wrote:
>> during a conversation with Angela yesterday came out that it might be to change RootImpl to be abstract (e.g. AbstractRoot) making also
> 
> Makes sense given there are enough commonalities to share. Have a look 
> at MutableTree, ImmutableTree and its common ancestor AbstractTree. I 
> think we should follow this pattern for Root.
> 
> Michael

Re: RootImpl to AbstractRoot

[Michael Dürig <md...@apache.org>]

On 24.7.13 11:52, Antonio Sanso wrote:
> during a conversation with Angela yesterday came out that it might be to change RootImpl to be abstract (e.g. AbstractRoot) making also

Makes sense given there are enough commonalities to share. Have a look 
at MutableTree, ImmutableTree and its common ancestor AbstractTree. I 
think we should follow this pattern for Root.

Michael