On 24 November 2011 18:23, Carsten Ziegeler <[email protected]> wrote: > 2011/11/23 Alexander Klimetschek <[email protected]>: >> On 23.11.11 12:57, "Vidar Ramdal" <[email protected]> wrote: >>>2011/11/23 Tobias Bocanegra <[email protected]>: >>>> I would rather put effort in creating connectors in jackrabbit. So >>>> having a LDAP, noSQL, etc. mapped into JCR brings much more value and >>>> having them on the resource level. >>> >>>Out of curiosity, for what reasons? >> >> Because all the infrastructure level things like ACLs (as in this >> discussion) won't have to be reinvented. The Sling resource API would >> evolve and become more complicated - and loose it's original purpose of a >> simple read oriented API, simpler than JCR in comparison. But not a >> standard. >> >> One of the goals of JCR was to provide unified access to data silos ;-) It >> might be a bit more work to implement JCR API parts (though the Jackrabbit >> and jcr-commons parts help a lot), but in the overall picture it provides >> more benefit IMO. >> > The Sling resource API is intented to provide full CRUD operations - > this has always been the case but we just haven't implemented > everything yet. And I think you're still missunderstanding this > proposal and what it is about. > > In addition, like I mentioned it several times in the past weeks, we > need to grow the community and I really believe that we have a fair > change if we directly support other NoSQL solutions. We won't grow if > we just support Jackrabbit.
I really hesitate to say this, but here goes: Over in Nakamura [1], we found our users really needed shallow wide hierarchies, so we built a content system and plumbed it into Sling using the ResourceProvider route. It works Ok (we dont list children) but still requires the JcrResourceResolver at the root of the content tree. The additional content system provider is also registered at /, but all searches happen first in JCR, and if not found there, the second content system is used. Sling still deploys with Jackrabbit, and its used for what I would call "Enterprise content", whereas the other content system is used for what I call "user generated content". Underneath the other content system we store in RDBMs's in the same way that the old YouTube meta data[2] system did. It can also store in HBase, Cassandra and MongoDB thanks to work by others. (2x GSoC + 1x contribution). Its not a standard like JCR or LDAP, and nothing like as capable as Jackrabbit, but it is an alternative store. I did this against a version of Sling from about a year ago and didn't find any major issues other than NonExistingResources. In the end I dont think we needed any patches to the Sling code. The one areas where we did need patches was to create a Jackrabbit UserManager impl that was baked up by the other content system so that when a session in Sling was established, it could be adapted into a session in the other content system. [3] I am not certain if its the right way of doing this, which is why I hesitate to mention it, and in places its almost certainly quick and dirty, rather than clean and elegant. If you are thinking of something clean and elegant, this may just be a distraction. Ian 1 https://github.com/ieb/open-experiments/tree/master/bundles/resource/src/main/java/org/sakaiproject/nakamura/resource/lite 2 I say YouTube only becuase when the VP of YouTube gave a talk at the Cambridge Computer Lab and presented the early meta data model in mysql it matched quite closely what was had already been implemented. I guess that talk influenced future work and adapted some of the sharding that was present. 3 https://github.com/ieb/open-experiments/blob/master/bundles/server/src/main/java/org/sakaiproject/nakamura/lite/jackrabbit/SparseMapUserManager.java > > Anyways, what about comparing Vidar's LDAP implementation with a > different implementation leveraging JCR? We can then play around and > see what works and what's best. > > Regards > Carsten > -- > Carsten Ziegeler > [email protected] >
