Hi David, David Nuescheler schrieb: > 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.
That's exactly why the resource tree is crucial: It provides a single entry point into the resolution of resources. What we might expose as part of the resources is an indication for informational purposes of the actual resource provider, for example by adding a (string) provider ID to the ResourceMetadata. > > 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 I agree wholeheartedly. It is not the intent -- and certainly will never be -- to expose access control services in the resource tree. Enforcement of access control will remain an implementation detail of the respective ResourceProvider. In the case of the JCR ResourceProvider, access control is enforced by the underlying JCR instance. What is exposed in a certain way, is access to authentication facilities. This is required for the ResourceProviders to be able to enforce access control. > api into a proprietary resource api with the same feature set seriously > is the wrong path. "Proprietary" is IMHO not the correct wording here. And as I said multiple times before, we are not going to duplicate the JCR API into the resource API. But this must not prevent us from extending the resource API where we see fit. Regards Felix > 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. >> > > >
