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" <[email protected]> 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 >
