On Mon, Nov 10, 2008 at 10:48 AM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: >> 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.
Right, that's why I proposed the ideas below which would make it simpler (let's say only these make it even possible) to do this virtualization on the repository level (jcr api) instead on the sling level (resource api). > >> 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. But Sling itself is a JCR application, and for core-features it cannot rely on propietary features of JCR implementations. >> 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' :-) No, I mean a framework for building a JCR connector that provides a simpler API working mostly around nt:file/folder on the JCR side. But the actual implementation (eg. filesystem or JAR) should be open. Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
