On 11/10/08, Alexander Klimetschek <[EMAIL PROTECTED]> wrote:
> 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.
but the main goal/focus of sling is to provide a framework for web
development based on a JCR repository. "mounting" different
technologies is the wrong approach. those resources should be
virtualized on the repository level and not on the sling level.

> 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
if you need that you can use a product that support virtual
repositories and provide connectors to 3rd party technologies.

>  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.
that would be a 'filesystem/jar connector' :-)

regards, toby

Reply via email to