Hi, This is a longish email which I wrote in bursts over a few hours, so I apologize in advance if it's not completely coherent. Basically, I think we should do both... allow for the request's workspace to be used for script resolution AND provide the ability to mount non-default workspaces under the resource tree (i.e. /security -> the root node of the security workspace).
On 3/18/10 2:19 AM, Carsten Ziegeler wrote: > Right, the question here is how to solve use cases like Justin's and I > think that solving this through the resource tree is the most elegant > way (and we have nearly everything for this in place since we started > with the resource tree). > > Carsten I thought about this a lot yesterday and I'm still of the mind mounting workspaces inside the resource tree is NOT the right way to accomplish the use cases I sent. This isn't to say we shouldn't do that, but I think we're fundamentally describing two different things. To my mind, at present Sling's resource tree is composed of a JCR workspace with 0 or more resource providers layered on top of the workspace's node tree (bundle, fs, etc.). For the purpose of the use cases I described yesterday, I am talking about replacing the base layer of the resource tree. We allow this today, it just doesn't work for script resolution (because of the specific need in script resolution to use a different session). I can see how a combination of mounting non-default workspaces and /etc/map can accomplish some of what I described. However, since both /etc/map and SlingServletResolver.getSearchPath() are static, it feels very limited. For example, if I wanted to service a request for http://v1.site.com/content/index.html using a node called /content/index and a script in a node /apps/myco/page, where both nodes are in the v1 workspace, I would need an /etc/map entry with v1.site.com sling:internalRedirect=/v1 AND the search path needs to be /v1/apps, /v1/libs, /apps, /libs Then I add v2. v2.site.com sling:internalRedirect=/v2 AND the search path needs to be /v2/apps, v2/libs, /v1/apps, /v1/libs, /apps, /libs There is now no way to properly serve scripts from v1 anymore (AFAICT). Perhaps a different way of looking at this... ResourceResolverFactory needs a method that says "create a new ResourceResolver, using this other ResourceResolver as a guide, but with alternate authentication." Looking at SlingServletResolver, something like this is needed anyway in order to make SlingServletResolver independent of JCR. Again, none of this is to say that we shouldn't ALSO do a secondary resource provider which mounts a non-default workspace within the resource tree. Finally, it's worth noting that mounting additional workspaces under the resource tree doesn't obviate the need for initial content loading and observation/event support across multiple workspaces. In fact, it makes the latter more complicated in that JCRResourceListener now needs to map a path in a non-default workspace to an absolute resource path. I would be surprised if JCRResourceListener was the only place we assumed that JCR path == resource path. Justin
