I've seen this API (mentioned) before, and I don't understand why it has to get passed onto the ResourceProvider to handle the logic. It could instead be ResourceProvider agnostic, so always available/functioning no matter what providers are around/in use.
Continuing to depend on ResourceProviders for such functionality (especially a query language this basic that could just be done through standard Sling resource visitation/navigation/iteration) doesn't seem all that beneficial, it just seems to add more complexity to the ResourceProviders that already have enough complexity as they are. On Thu, Jun 16, 2016 at 10:43 PM, Carsten Ziegeler <cziege...@apache.org> wrote: > Jason E Bailey wrote >> Which api proposal is that? >> > > https://issues.apache.org/jira/browse/SLING-4752 > > Carsten > >> -- >> Jason >> >> >> >> On Thu, Jun 16, 2016, at 01:14 AM, Carsten Ziegeler wrote: >>> Steven Walters wrote >>>> The other providers sling manages in its codebase don't appear to >>>> get much >>>> TLC, such as that they're all still using the older deprecated >>>> ResourceProvider system, instead of the new one (which the JCR >>>> ResourceProvider does use). >>>> >>>> Also, it appears that a number of the sling >>>> components/functionalities >>>> still require the JCR, such as >>>> * Eventing/Jobs, by mandating node types and using JCR queries to >>>> retrieve >>>> them. >>>> * Generic Sling Post Servlet functionality, in that the >>>> import/contentloader functionality of it still utilizes the JCR >>>> APIs for >>>> the creation of data. >>>> >>>> This is just some things I've seen so far from working on my own >>>> ResourceProvider as well. >>>> >>>> So some portions of Sling can work without JCR but it still >>>> remains that >>>> some portions of functionality still cannot work without JCR >>>> currently. >>>> >>>> The Sling Post functionality will be on the easier side to alter to >>>> be JCR >>>> independent, but Eventing will require more thought as to what to >>>> do about >>>> the queries. >>>> >>> >>> We have a proposal for an API extension to solve that problem. Only >>> thing missing is someone implementing it :) >>> >>> Carsten >>> >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> cziege...@apache.org >> >> > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
