On Tue, Mar 14, 2017 at 2:11 PM, Stefan Seifert <[email protected]> wrote: >> Konrad wrote: >>...I would be in favour of reusing the Resource interface from Sling API... > > ...this would open a can of worms because we would have to support all of it > including ResourceResolver etc. > or we leave a lot of methods throwing exceptions or returning null which > would not be nice either....
I agree with Stefan that it's good to be able to represent a content tree in such utility libraries with no or minimal dependencies on Sling. The other use case that I have in mind is serializing content for sending to and receiving from external content processors that should be very independent from Sling, and this is a good step in that direction. Using the Resource API introduces a lot of transient dependencies that I much prefer leaving out for such cases. I like Stefan's Content proposal but it's really a ContentTree, right? And we might move that API to its own module to make it independently reusable. Maybe later. -Bertrand
