Hi Carsten
Overall I welcome a cleanup in this area, so +1.
I have some concerns about the provider always owning the root,
however. I understand that this makes it easier to have good
performance by default. But I also believe that there are use-cases
where it is desirable to enhance a resource tree that is predominantly
provided by another provider. E.g. add a child resource called
"accessStats" blow every resource of type "page", or the
{{SuperimposingResourceProvider}}.
How could these scenarios be implemented? Maybe they could proxy all
calls, but this would require that they can easily query "all
providers except themselves". But then all calls would be proxied,
potentially leading to multiple layers of delegation.
Maybe someone else has a better idea?!
Regards
Julian
On Mon, May 18, 2015 at 8:17 AM, Carsten Ziegeler <[email protected]> wrote:
> The resource provider API has grown a lot over time and when we started
> with it we didn't really think about potential extensions of the api.
> Today, each time we add a new feature, we come up with a new marker
> interface. There is also the distinction between a resource provider
> (singleton/stateless) and the factory (creating stateful providers).
> Although the api is not intended to be used by the average resource api
> user (it's an extension), we put it in the same package. And there are
> more minor things.
>
> Therefore I think it's time to start a new API that is more future proof
> and solves the known problems. I've created a draft prototype at [1].
>
> During the performance analysis by Joel he found out that getParent
> calls to a resource a pretty expensive as in the end these are string
> based. Therefore, e.g. the JCR implementation can't simply call
> getParent on a node and wrap it in a resource. Therefore I think we
> should add a getParent(Resource) method to the resource resolver and
> have a better way to handle this in a resource provider.
>
> Instead of having a resource provider and a resource provider factory,
> we define a single ResourceProvider which is a singleton. If this
> provider needs authentication and/or needs to keep state per user, the
> PROPERTY_AUTHENTICATE needs to be set to true and in this case the
> authenticate method is called. This one returns a data object which is
> passed in to each and every method. If auth is not required, the method
> is not called and null is passed in as the data object.
> For authentication, providers do not support login administrative
> anymore, just users and service users.
>
> A provider is mounted at a single root - no more support for mounting it
> at different path at the same time; and a provider always owns the root.
> So if a provider does not return a resource for a given path, no other
> provider is asked. This allows for improved implementations and resource
> resolving. If we decided that we need this for compatibility we can
> solve it differently.
>
> Instead of using marker interface, we define the ResourceProvider as an
> abstract class. This allows us to add new methods without breaking
> existing providers.
>
> Each method gets a ResolveContext, containing the resource resolver,
> the previously mentioned state data object and other things, e.g. the
> parameter support recently added to the resource resolving. In the
> future we can pass in additional data without breaking the interface.
>
> Apart from that the resource provider is similar to the aggregation of
> the already existing marker interfaces. There are two exceptions,
> observation and query which I'll handle in different emails.
>
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/provider/
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> [email protected]
