Alexander Klimetschek wrote > On 14.01.11 22:33, "Carl Hall" <[email protected]> wrote: >> >> On Fri, Jan 14, 2011 at 2:47 AM, Carsten Ziegeler >> <[email protected]>wrote: >>> We have more features on our list for the resource resolver >>> (factory/provider) which would allow to create, update and delete >>> resources as well (I think there is a wiki page regarding this). So if >>> you need something in this area, maybe it's now a good time to address >>> these things >> >> The resource resolver and resource provider have been invaluable to us. >> The >> resource layer in general has made our work much easier. > > Please note that the current value of the resource API over the JCR API is > only that it is simpler, thus more quickly to implement with some custom > backend. If more and more is added to the Resource API, especially all the > complexities of write operations, this value will be completely lost, and > I would urge everyone doing so to implement the needed subset of the JCR > API instead. > > Federation/virtual mounting (which is another useful feature of the > resource API) can also be done with the JCR API as modeshape shows or > something that we have in our proprietary CRX repository here at Adobe/Day. > > It all just boils down to the development effort... but with JCR you get a > well-though out standard. > And with Sling's resource API you get an even simpler API on top of it :)
At one point in time, we'll be able to do CRUD through the resource api, it's not much left to do there anyway and this will allow to write complete applications just based on the resource api. And developers will benefit from all the Sling features - In contrast to JCR which is an API, Sling is a framework with the aim to make developers live easier. I see a lot of benefits, use cases and scenarios where the current available (open source ) implementations are lacking functionality. In addition, I have use cases where I want to run Sling without a repository underneath or with several different repository mount at different locations in the resource tree. Just think about how easy it is to mount a file directory or resources from within a bundle into the resource tree - this works today. Of course this is doable from within a repository, but especially when I think about OSGi resources it seems like the wrong approach :) I don't see the Sling API competing with the JCR API - as I said, Sling is framework :) Regards Carsten -- Carsten Ziegeler [email protected]
