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

Reply via email to