For the CRUD case, I agree that it depends. However for the use cases we have, its used to overlay a predefined configuration based on search paths. And this means something under /libs is never changed, all changes happen under /apps. That's pretty easy to implement and I already have the implementation for the current provider with a set of test cases. If you don't provide CRUD writing the UI is much harder and requires knowlege of the merging algorithm: you get the resource from /mnt/somewhere but the logic needs to know to change stuff at /apps/somewhere and then how. It's completicated and you have to do this for each and every ui. And as I said, we can add a flag for CRUD support, maybe off by default.
Carsten 2014-08-30 5:29 GMT+02:00 Alexander Klimetschek <[email protected]>: > 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] > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
