Everything is a Resource

[Hendy Irawan <he...@soluvas.com>]

Dear Sling community,

I'd like to say thank you very much for developing Sling! It's really a
great framework!

>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.)

Thank you.

-- 
Best regards,
Hendy Irawan
+62 81-2210-66622 :: +62 22-91853265
http://www.hendyirawan.com/ :: hendy@soluvas.com

Re: Everything is a Resource

[Alexander Klimetschek <ak...@day.com>]

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.klimetschek@day.com