Am 16.10.15 um 11:38 schrieb Joel Richard: > Hi, > > With the new ResourceProvider API, the Merging ResourcePicker has already > much less overhead. Nevertheless, there is still quite some potential which I > would like to discuss here: > > Let’s assume that we have two base paths, /libs and /apps. In most cases, the > resources from /libs are not overlaid in /apps. If we want to get a resource > from /mnt/overlay, then we are obviously forced to check both base paths if > the resource exists there. However, if we later use getChild to retrieve a > child resource, it would be much more efficient to simply ignore all base > paths where the parent resource does not exist. > > Moreover, the MergingResourceProvider will check for each overlying resource > if the parent resource has a sling:hideChildren property. Even if the child > does not exist, it has still to use a getResource call to check if the parent > exists and has such a property because if so then it would affect the > underlying resource as well. Therefore, it would be better to read in the > MergingResourcePicker for overlying resource first the parent and only if it > exists the child. If the parent or child does not exist, it could create a > special NonExistingResource which has a getParent method which returns the > previously read parent. > > Unfortunately, both of these optimisations are not entirely correct because > in some ResourceProviders it is possible to configure ACLs so that the parent > of a readable child is not readable. Personally, I don’t think it’s > acceptable that a use case which is rarely used has such a big impact on the > performance. Therefore, I am wondering what to do here. > > - Should we just accept the current situation? > - Should we implement these optimisations anyway? > - Should we cache paths of non-existing overlying resources? > - Should we use an admin/service resource resolver to get an idea of the real > structure of the overlays? > > I fear there is no good solution for this problem, but I hope that somebody > has another idea what could be done here. >
Thinking about this again :) We could apply the optimisations and simply see how it goes. If there are problems, we can make it configurable either with a global switch or even path based. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
