[OASIS Issue Tracker] (CMIS-758) Discussion of more powerful batch operations for next version

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/CMIS-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60608#comment-60608 ] 

Florian Mueller commented on CMIS-758:
--------------------------------------

I would like to pick up the batch topic again and look at it from a new angle.

The easiest way is probably to send a sequence of HTTP requests as a batch instead of defining our own batch format. Other standards and projects have done this before [1][2].
The basic idea is that one multipart/mixed message contains multiple HTTP requests. The server replies with a multipart/mixed message that contains the responses of the requests. This is a rather simple mechanism.

The URL that accepts batches could be provided in the repository info. If it is missing, the repository doesn't support batching.

For CMIS we would have to define a few semantics, though. For examples, what happens if one operation fails? And how to deal with long running operations that exceed the HTTP timeout?
The client could control these with URL parameters. Here are few suggestions.

Parameter: processing
Values:
- continueOnFailure [default]: The repository should execute all operations, even if one or more fail.
- haltOnFailure: The repository should stop when the first operations fails.
- atomic: The repository should stop when the first operations fails and rollback back all executed operations. A repository may reject such a request if atomic processing is not supported.

Parameter: order
Values:
- strict [default]: The repository must execute the operations in exactly the order provided by the client.
- allowReorder: The repository may change the order of the operations, if it is more efficient. All operations are independent of each other.
- allowParallel: The repository may execute the operations in parallel, if it is more efficient. All operations are independent of each other. Should not be combined with processing= haltOnFailure.

Parameter: response
Values:
- direct [default]: The repository sends the results of the operations in the response of batch request (HTTP status code 200). If a HTTP timeout occurs during execution, the server should complete the execution of the batch, but the client will get no or an incomplete response.
- poll: The repository confirms that request has been accepted and provides a URL in the Location header that the client can use later to poll for the results (HTTP status code 201). This requires a stateful server and a repository may reject such a request.
- none: The repository only has to confirm that the request has been accepted (HTTP status code 202). The client is not interested in the results.


Side note 1: It doesn't really work with the Web Services binding.

Side note 2: That would work as a CMIS extension for 1.0 and 1.1. We don't have to wait for CMIS 2.0.

Side note 3: With the Browser binding it would be possible to build a folder hierarchy in a batch because folders can be addressed by path in Browser binding URLs. 


WDYT?


[1] http://www.odata.org/documentation/odata-version-3-0/batch-processing/

[2] https://cloud.google.com/storage/docs/json_api/v1/how-tos/batch

> Discussion of more powerful batch operations for next version
> -------------------------------------------------------------
>
>                 Key: CMIS-758
>                 URL: https://issues.oasis-open.org/browse/CMIS-758
>             Project: OASIS Content Management Interoperability Services (CMIS) TC
>          Issue Type: New Feature
>          Components: Domain Model
>    Affects Versions: Proposals for 2.0
>            Reporter: Jay Brown
>
> Creating this record as a placeholder for discussions on this subject. 
> What additional batch features should we support in v.next? (e.g.  batch Create, Delete, ...) 
> What should they look like? etc. 
> Please comment.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)