sling without a jcrResourceProvider

[Jason Bailey <Ja...@sas.com>]

Has anyone played around with using Sling without utilizing the JCR resource provider and utilizing one of the other providers instead?

-Jason 

Re: sling without a jcrResourceProvider

[Carsten Ziegeler <cz...@apache.org>]

Jason E Bailey wrote
> Looking at the API I actually have something similar already written
> that uses a resource as a starting point and iterates down through the
> child resources to perform the query. 
> 
> In that manner it's agnostic as to what's providing the resource,  as
> long as we are able to obtain the children of a resource.

Right, which is one way of implementing that API. The first thing is to
have an API clients can use to query, and the proposed client API is a
separate API which can be implemented in any way.

> 
> Since it's possible for the children of a resource to be provided by
> multiple resource providers, handing off the queries to be handled by
> multiple resource providers may improve the speed of the query.
> Additionally, you mentioned each resource provider may optionally cache
> the internal results,  however you would then still need to consolidate
> that set of data and apply ranges and limits, which I don't believe
> could be done effectively from within the resource provider itself.

I think I didn't mean caching the result, but rather creating the
underlying query for the provider (parsing the data objects etc.).

> 
> Alternatively, since I've had the same experience that Steve has had
> with iterative searching, an external iteration  does not require that
> the resource provider do anything more than what it currently does which
> is to identify a resource and it's children. 
> 

This all depends on how useful/effective you value the search feature of
the underlying provider.
From what I understand here, there seem to be cases where that is not
efficient and traversing is more efficient. But I wouldn't generalize
this and say that for every query a traversal is more efficient.
Traversing becomes also more problematic when you want pagination,
sorting etc.

As said, the client API does not really define how the search is done.
So both ways are possible, implementable.
 
But I think, discussing query vs traversal is a great topic for the Oak
list as most of the experts are there (and I'm not implying that there
are no search experts on this list)

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: sling without a jcrResourceProvider

[Jason E Bailey <ja...@24601.org>]

Looking at the API I actually have something similar already written
that uses a resource as a starting point and iterates down through the
child resources to perform the query. 

In that manner it's agnostic as to what's providing the resource,  as
long as we are able to obtain the children of a resource.

Since it's possible for the children of a resource to be provided by
multiple resource providers, handing off the queries to be handled by
multiple resource providers may improve the speed of the query.
Additionally, you mentioned each resource provider may optionally cache
the internal results,  however you would then still need to consolidate
that set of data and apply ranges and limits, which I don't believe
could be done effectively from within the resource provider itself.

Alternatively, since I've had the same experience that Steve has had
with iterative searching, an external iteration  does not require that
the resource provider do anything more than what it currently does which
is to identify a resource and it's children. 


--
Jason

On Thu, Jun 16, 2016, at 10:50 AM, Carsten Ziegeler wrote:
> Steven Walters wrote
> > 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.
> 
> Really? How?
> 
> Carsten
> 
> > 
> > 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.
> > 
> 
> 
> 
>  
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org

Re: sling without a jcrResourceProvider

[Carsten Ziegeler <cz...@apache.org>]

Steven Walters wrote
> 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.

Really? How?

Carsten

> 
> 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.
> 



 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: sling without a jcrResourceProvider

[Steven Walters <ke...@gmail.com>]

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 <cz...@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
>>> cziegeler@apache.org
>>
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org

Re: sling without a jcrResourceProvider

[Carsten Ziegeler <cz...@apache.org>]

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
>> cziegeler@apache.org
>  
> 


 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: sling without a jcrResourceProvider

[Jason E Bailey <ja...@24601.org>]

Which api proposal is that?
 
--
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
> cziegeler@apache.org
 

Re: sling without a jcrResourceProvider

[Carsten Ziegeler <cz...@apache.org>]

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
cziegeler@apache.org

Re: sling without a jcrResourceProvider

[Steven Walters <ke...@gmail.com>]

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.

On Wed, Jun 15, 2016 at 11:20 PM, Jason Bailey <Ja...@sas.com> wrote:

> Has anyone played around with using Sling without utilizing the JCR
> resource provider and utilizing one of the other providers instead?
>
> -Jason
>