Improve Document.Create and Document.Update operations

In the context of Android SDK, I use Automation API to Create and Update documents.

• Document.Create
• Document.Update

I hit some limitations I would like to fix, and since I don't want to add new Create/Update operation, I plan to update the existing ones.

There are several aspects :

Complex types

Create/Update operation use Properties to represent the data to be added.
From my understanding it does not allow Complex properties, only scalar and List<String> are managed.

On the automationClient complex properties are represented as PropertyMap.
=> I would like to allow a value in the properties to be expressed as a JSONObject like :

dc:title = my title
file:content =

{filename="toto.txt", mimetype="text/plain" ...}

Blobs management

The current way of adding a Blob to a document is to call Document.AttachBlob.
My problem is that if I create a Document with some properties and want to attache 2 Blobs :

• I have to create a dedicated chain so that I have only one Http Call (then 1 Tx)
• I have to post all content as multi-part encoded

In the context of Android I don't really like this idea :

• I would lile to rely as much as possible on built-in Operations
• I can not easily do a multipart post (ok, I am lazy)
• I don't want to have a big post : If network connectivity comes and goes having big post is not a good idea

I had similar problems with Html5 Dnd and JS.
So I added to Automation server :

• an API to upload Blobs one by one and associate them to a batchId
• run an operation Chain that will use these Blobs as input
  It works because in the Dnd use case I want to create one document per blob

In the Andoid case I would like to :

• upload the Blobs and associated them to a give batchId
• call Create/Update
• have complexe Blob properties sent as parameter referece the Blobs

dc:title = my title
file:content =

{batchId="XXX", batchFileIdx="0"}

Conflict management

Because Android will support Offline updates it will introduce the risk of dirty update.

Here again I would like to have a standard system to handle that

=> integrate in standard Create/Update operation

For conflix detection, my plan is to rely on an additionnal ChangeToken that can be passed to the Operation.

The CMIS base object-type definitions include an opaque string "ChangeToken" property that a Repository MAY use for optimistic locking and/or concurrency checking to ensure that user updates do not conflict

As a first step, we can use dc:modified even if it's not ideal.

Conflict detection

Add a parameter ChangeToken parameter to the Create/Update operation

=> if the parameter is set, the operation should check for Diry update

==> in case of problem it should raise a Exception and ideally automation server should send back an Http 409 Conflict return code

Conflict resolution

Once conflict is detected, the client can choose to abandon his changes and refetch from the server.
In the other case, we should allow the client to force push :

• either ommit ChangeToken parameter to bypass the check
• use an other parameter that asks the server to do something like :
• save previous version as a version
• save client update with a comment
• create a task for managing merge ?

Related ticket : https://jira.nuxeo.com/browse/NXP-6351