On 01.03.2014, at 01:56, Carsten Ziegeler <[email protected]> wrote:
> It is not correct, that we added a merge() method which "completely misses > the point". No, you did not add that merge() method at all :) It's basically now the getMergedResource(Resource) method, which is FIXED to the sling search path. And this is the part that is wrong - it reduces the merger service to one use case only and doesn't allow reuse. > The service has just path handling methods, everything else is > done consistently in the resource provider. And it is done exactly as has > been specified / requested in the original issue. Ok, yes, the getResourcePath() method is not as I assumed it and described it in my mail - it just gives information back on what currently would be the real resource path used. I think this would be better (and IIRC was in Gilles' original patch) to expose the MergedResource interface and provide it with the necessary "insight" methods. I.e. ResourceMergerService would return MergedResource directly in its getMergedResource() (current API) or merge() (my proposal). > I think adding a merge() method which allows to create resources that are > not available via a resource resolver will create all kinds of problems. > Even worse, it allows you to create a resource at any arbitrary path like > /libs/hello/world and pass this on to other services, totally confusing the > whole system. No: - the resulting "virtual" path (say /mnt/overlay) would not and should never be the same as any existing one (/libs) - the merger service itself doesn't hook in automatically anywhere; applications have to call it explicitly, and know what they are doing, which is perfectly fine here > Such a resource is never available via the typical resource resolution - so > all the concepts of Sling like the REST api for getting resources and > manipulating them does absolutely not apply. Or even traversing based on > such a resource is not possible. Why is traversing not possible? Was that feature removed? It worked fine in Gilles original implementation. > Or in short, such a service method is bypassing all of Sling's concepts. I don't understand. The purpose is a generic merge mechanism. Sling search paths are just one way of doing this. The main purpose is the "protocol" to merge resources, i.e. to patch something (prefer one over the other, delete one resource or property, replace property values, etc.). What list of resources to merge is a separate concern - left to the application. Also, don't assume that the ResourceMerger service itself already is a ResourceProvider. One can implement a resource provider using the merger service (as done for /mnt/overlay) but it doesn't have to be that way. (Although it will likely be the typical case to do it via a resource provider, and then having multiple ones, say /mnt/overlay, /mnt/component-dialogs, ....). > If an application really wants to create fake resources for whatever > reason, the application is free to provide such a service. But I'm > reluctant to add anything like that to Sling. If you think this doesn't belong into Sling, then ok, let's move the resource merger API outside Sling. Cheers, Alex
