On 17.01.11 16:00, "Carsten Ziegeler" <[email protected]> wrote: >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.
Yes, but we are talking specifically about the Sling Resource API here. And so far that has been geared towards a read-only, small and efficient API, that is easy to use. Which it implemented perfectly. However, I strongly expect that adding write operations in the API will make it "too" complex. Especially because then you open a whole new set of wishes from all sides, which in the end will not give you a good API, I think. >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 agree, and I don't propose to take the resource API away. All I am saying is that it should be kept read-only. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
