hi guys, i don't have an opinion on the organization of code, so cleaning things up is always good.
what i would strongly caution though is fostering the divergence between the resource tree and the node tree. since there are good tools to browse, search and manage the node tree this is really one of the main advantages that sling brings to the table opposed to many of the other web frameworks. the url mapping to content nodes is simple and straight forward similar to the fs mapping in a static webserver. this transparency is taken away when we have a resource tree that diverges from the node tree. or in a simple example: to find out what happens when a request goes to /bin/... is almost impossible and going through all the configurations of all the bundles and the respective sling.servlet.paths to find out what's going on in the system is definitely not efficient. starting to expose services like access control on the resource tree is something that i find dangerous and problematic. access control should really be enforced at the data (jcr) layer and slowly copying the entire jcr api into a proprietary resource api with the same feature set seriously is the wrong path. i would really like to get rid of the duality of these two api's that essentially will do the same same thing in the long run. just my two cents, regards, david On Sun, Nov 9, 2008 at 7:28 PM, Juanjo Vázquez <[EMAIL PROTECTED]> wrote: >> The proposal also allows for much more >> flexibility in building the Resource tree made of ResourceProviders >> where each ResourceProvider itself may actually be provided by a >> ResourceProviderFactory. > > > Felix, this implementation would allow to have an only one security > management for the whole virtual resources tree, really?. I understand this > is not possible until now. > > BR, > > Juanjo. > -- Visit: http://dev.day.com/
