Alexander Klimetschek wrote > 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. > 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 -- Carsten Ziegeler cziege...@apache.org
