Hi all! On Sun, Nov 9, 2008 at 11:35 PM, David Nuescheler <[EMAIL PROTECTED]> wrote: > 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
I think it's only the credentials that are passed through the resource API, the underlying JCR will still provide the ACL handling. > 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. Currently main advantage of the resource tree in Sling is that it is simpler to plug-in different implementations (eg. bundleresourceprovider, external databases, external jcrs, etc.) than with JCR (Jackrabbit) itself. Jackrabbit's SPI tries to simplify the implementation of a JCR repository backend or adapter to an existing repository or database, but it is still a lot of work and it is not standardized on the JCR level. IMHO Sling could work on the JCR API if the API itself would have 1) a "mount-repository"-feature (ie. allows to mount a remote JCR inside the tree) and 2) if there was a pre-built implementation of the JCR API that just requires to implement a simple filesystem-style API itself to quickly implement simple things such as the bundleresourceprovider for eg. loading classes from JARs while being still fully JCR compatible. Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
