On Fri, Jul 3, 2009 at 7:06 AM, Hendy Irawan<he...@soluvas.com> wrote: > From http://sling.apache.org/site/resources.html I have the understand that > Sling adds an abstraction named Resource above the JCR Repository. > > I wonder how it compares to the approach of having an outer layer of JCR > Repository instead, i.e. the "Resource layer" is actually a valid JCR > Repository itself, that provides the "virtual tree of resources". With this > in mind it's possible to nest repositories to an arbitrary depth, similar to > the approach taken by virtual file systems (Commons VFS, FUSE, UNIX > mounting, etc.)
Not sure what you mean by "outer layer of JCR Repository" but the resource layer has these goals/features: - allow multiple backends (JCR or non-JCR) to be plugged in (not yet fully pluggable, but improving, see [1]) major use case for this are servlets and scripts provided as classpath resources in bundles - simplify (read) access to data, eg. using the ValueMap (simpler than direct JCR), without unnecessary checked exceptions etc. - IIRC also be independent of the connection to the JCR (eg. if it drops due to restart, network issues, etc.) It's right that in an ideal world you would do this on the JCR level, ie. have a JCR API implementation that actually allows mounting of different (JCR) backends and provides a virtualization layer through this (similar to what JBoss DNA is doing, IIUC). But due to the size of the JCR API, it's hard to quickly implement it for other backends, so Sling went the simple way. Jackrabbit does provide the SPI (Service Provider Interface), which is a simpler interface and especially allows for batch-operations optimized for remote JCR access, and proprietary JCR repositories such as CRX [2] allow some kind of virtualization, but these efforts are too young and not standardized yet. [1] http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html [2] http://www.day.com/crx Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
