[jira] [Commented] (SLING-4750) New Resource Provider API

["Bertrand Delacretaz (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14560616#comment-14560616 ] 

Bertrand Delacretaz commented on SLING-4750:
--------------------------------------------

Thanks for this! Note that in the meantime this moved to https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/spi/resource/provider/

Comments/questions about ResourceProvider and ResolveContext (QueryProvider is discussed in SLING-4752):

How to you see the transition from the existing APIs? Provide a bridge from the current APIs to the new ones?

In the comment of the provider.useResourceAccessSecurity, instead of "ResourceProvider implements are encouraged..." can we instead say "ResourceAccessSecurity should only be used when the underlying storage does not provide access control" ?

What's the use case for ResolveContext.getResolveParameters() ?

"rollback" would sound more natural to me than "revert" for that method's name.





> New Resource Provider API
> -------------------------
>
>                 Key: SLING-4750
>                 URL: https://issues.apache.org/jira/browse/SLING-4750
>             Project: Sling
>          Issue Type: Improvement
>          Components: API, JCR, ResourceResolver
>            Reporter: Carsten Ziegeler
>            Assignee: Carsten Ziegeler
>             Fix For: API 2.10.0, Resource Resolver 1.2.6
>
>
> Mail thread from the mailing list:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983ED.1080800%40apache.org%3E
> Starting mail:
> 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/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)