On 3/17/10 4:41 AM, Carsten Ziegeler wrote: > I'm not sure what the best way is, but Sling is resource tree based. The > resource resolver (factory) gets configured with resource search paths > (/apps and /libs is default) for scripts. > The script resolver uses these paths to search for scripts. The script > resolver uses an own session and therefore resource resolver which is > not related to the current request. This allows a more secure > installation as the current user does not have to have read rights for > the scripts (or any other access rights). > > In general I am not sure if it should be the authentication which > defines what workspace is used. I rather could picture having a resource > tree where workspaces are mounted at different locations in the tree. > The script resolution could then be configured to search in the various > workspaces. Hmmm. But then you'd have to have a different search path per user to handle the script preview case I mentioned in my response to Bertrand which seems like a significant performance issue.
In any case, I don't agree that the workspace name should be part of the resource tree. At that point, the workspace is essentially just a top-level node. When using workspaces for branching content/scripts/etc. it seems to make more sense to have the workspace name derived from something outside of the path. For example, if you think about how Google App Engine allows you to reference arbitrary versions of your application with a host name like version.appname.appspot.com (IIRC), one could imagine using the host header to select the workspace which corresponds to the requested version (and according to David's Model, this is a totally valid use of workspaces). Justin > > Carsten
