this is another idea from Santiago García Pimentel an API extension that affects both ResourceProvider SPI and the Resource/ResourceResolver API.
Provide a mechanism to order resources https://issues.apache.org/jira/browse/SLING-4741 some resource provider like JCR/oak can support this, others may not (e.g. the nosql resource provider currently always returns the resources sorted alphabetically to avoid storage of complex ordering info). stefan >-----Original Message----- >From: Carsten Ziegeler [mailto:[email protected]] >Sent: Monday, May 18, 2015 8:17 AM >To: Sling Developers >Subject: [RT] New Resource Provider API > >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]
