On Wed, Mar 17, 2010 at 16:07, Carsten Ziegeler <cziege...@apache.org> wrote: > Carsten Ziegeler wrote >> I still have the feeling that mounting other workspaces into the >> resource tree is the easier way. >> With that we wouldn't need to change content loading, resource events >> and maybe other things to come? >> >> Can we go a step back please and see what use cases we really have? >> > With the authentication info and the new resource resolver factory, we > will have a mechanism to log in the user optionaly into resource providers. > So for example if the authentication info contains a specific key/value > pair, a login to a workspace resource provider which mounts workspace > xyz at /xyz could be done. If the key/value pair is missing, the login > to this resource provider is not successful and therefore in this > resource tree /xyz does not exist. > > If now the resource resolver is configured to search scripts in > /xyz/scripts, /apps, /libs everything should work. > > Just a rough idea.
Hmm, this is interesting to see as in Jackrabbit we currently discuss that for Jackrabbit 3.0 (major rewrite wrt persistence and internal architecture) we would like to have a single tree in the persistence layer with each workspace being mounted directly below the root. Which is the same here ;-) I don't know too much of the (newer) internals of the resource tree and its creation, but I think adding an additional layer with workspaces by default creates new issues at various places. And it gives people an invitation to use workspaces for things they are not intended for (and in current Jackrabbit not optimized for!). That's why I would not make that a default. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
