The current Sling resource API only allows reading of resources - with the PersistableValueMap we have a simple mechanism to support updates, however this approach comes with some problems (see below).
This is a concept how to fully implement CRUD via the resource API. As a first step we angle the problem from the users via: the API to be used by Sling applications.
Client API
Read
The support for read is sufficient, we don't need to change that much.
Delete
We add a delete method to the Resource interface, so deleting a resource is a two way step: first getting the resource from the resource resolver and then deleting it. The change is persisted immediately (see below).
Create
We add a new method create(String absolutePath, ValueMap properties) to the resource resolver, where the value map is optional. This will create the resource at the given path and add the provided properties. The change is persisted immediately (see below)
In the case of a JCR backed repository, the properties might contain jcr:primaryType and jcr:mixins - which are used to set the node node and mixins. Otherwise the defaults apply.
Update
We currently have the PersistableValueMap which is an easy way of modifying a resource. As we have modifications now as a first class feature, we should add an update(ValueMap props) method to the Resource interface. The change is persisted immediately.
Persisting Changes
In general, a call to one of the methods, modifying a resource as outlined above are persisted immediately. However, transactions will be supported as well.
TBD Transaction handling
Resource Providers
A resource provider is mounted into the resource tree. In general, the providers are processed ordered by service ranking, highest first. A service provider gets a service property specifying the sub tree it is claiming to use. For example, a service provider might be mounted at /a/some/path. Everything below this path is processed by this resource resolver. However another resource provider might claim /a/some/path/and/down. So the longest matching path wins.
We need to add a new interface which can be implemented by a ResourceProvider. It gets a create method. Update and delete are directly handled by the resource.
Access Control
It's the task of a resource resolver to check if the current user is able/allowed to access a resource. If this is not possible, the corresponding action is denied.
As resource providers are mounted at a path (see above), the resource resolver delegates to a resource provider for a given path. If the user is not allowed to perform the action, the processing is stopped. There is no fallback to another resource provider. This avoids the problem that different users might see different resources (provided by different providers) depending on their rights.