The picker (or selector) as separate service sounds like a good compromise to me. Using that service directly would not give you a merged resource, so people would be forced to get such resources via the normal resource tree (/mnt/foo/bar), which is what we'd like to enforce.
I still think that merged resources can only be read-only and introducing CRUD would never work reliably. Simply because you have to decide between overwriting some existing content (/libs/sling/foo) vs. adding a new overlay (/apps/sling/foo), a decision you can't make with a single merged resource. It requires knowledge of the resource list (e.g. search path in case of the override one) and its semantics; an admin ui to configure that would have to work separate from the merger anyway; and it could simply be a JCR browser or some configuration UI fixed to a certain path (say always changing global settings or the ones from a specific tenant). Cheers, Alex On 28.08.2014, at 04:36, Carsten Ziegeler <[email protected]> wrote: > Hi Justin, > > yepp I was going to comment on the name as well :) We definitely should > avoid "Selector". > With this mechanism, we always use the same merging algorithm and "only" > make the source > for merging pluggable. > Sounds like a good compromise, at least we're not leaking any fake > resources. > > And this would still work with optionally supporting CRUD (Picker could set > a serive prop for that). > > Carsten > > > 2014-08-28 13:28 GMT+02:00 Justin Edelson <[email protected]>: > >> Hi Carsten, >> Yes that is essentially the idea. >> >> You may be correct that a second selector method is necessary; I >> haven't figured out all of the details yet, but I wanted to get some >> conensus on the concept before diving in. >> >> Also, it occurs to me that "Picker" might be better than "Selector" as >> we use that term to mean something else in Sling. >> >> Justin >> >> On Thu, Aug 28, 2014 at 4:45 AM, Carsten Ziegeler <[email protected]> >> wrote: >>> Hi Justin, >>> >>> I'm not sure if I understand this proposal completely. >>> So let's assume the current merge provider would be implemented with >> this, >>> it would register this selector service with the root property set to >>> /mnt/merge. >>> This gets picked up and a resource provider with the same root is >>> registered. >>> When now a resource is requested from the provider, like >>> /mnt/merge/foo/baa, the selector service is called first with /foo/baa as >>> the second parameter and it would return the existing resources relative >> to >>> the search paths, so e.g. /libs/foo/baa and /apps/foo/baa. The merge is >>> done and the merged resource is returned by the provider. >>> Is this roughly what you are envisioning? >>> This could work, however I fear we need two methods - like we have in the >>> provider interface: one for getting a resource at a specific path and one >>> to list the children. >>> >>> Carsten >>> >>> >>> 2014-08-27 21:50 GMT+02:00 Justin Edelson <[email protected]>: >>> >>>> Hi, >>>> We still seem to have a disagreement about the benefits/wisdom of >>>> exposing a service which merges resources. I have an alternative which >>>> I think solves for both the desire to have flexible resource selection >>>> algorithms and not expose resources outside the context of the >>>> ResourceResolver. >>>> >>>> We create a SPI interface called MergedResourceSelector. This has a >>>> single method: >>>> >>>> Iterator<Resource> selectResourcesToMerge(ResourceResolver, String) >>>> >>>> OSGi services implementing this interface must also have a merge.root >>>> service property. >>>> >>>> In the resource merger bundle, we have a whiteboard which listens for >>>> these services and, for each, it registers a ResourceProviderFactory >>>> which references the Selector service and uses the merge.root service >>>> property for the provider.roots property of the >>>> ResourceProviderFactory. The ResourceProvider is an implementation >>>> detail of the resourcemerger bundle. >>>> >>>> This is essentially what I'm trying to implement anyway (where the >>>> AbstractMergingResourceProvider has all of the merging logic) for >>>> SLING-3657; the only difference is that rather than using a class >>>> hierarchy, we use OSGi services. >>>> >>>> >>>> WDYT? >>>> >>>> Justin >>>> >>> >>> >>> >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> [email protected] >> > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
