I had thought this would be a system (read only) property. Can you further describe the situation you are thinking of where a client would want to set this and what would be done with those values?
For example, if the server is using algorithm sA and a CMIS client adds an additional hash value for algorithm cB when they set the stream on a new document:
(Post Create) The client would still have to use the server's algorithm (sA) to determine if the file arrived intact.
Also, the other hash values not maintained by the server (client only hash values) could quickly become stale when other clients that don't know or care about cB modify the file. So even CMIS clients would not be able to trust them.
Jay Brown
Senior Engineer, ECM Development
IBM Software Group
jay.brown@us.ibm.com
Greg Melahn ---12/06/2013 06:31:53 AM---hi Florian, Great idea to add a hash!
From:
Greg Melahn <greg.melahn@alfresco.com>
To:
"Mr. Florian Mueller" <florian.mueller02@sap.com>,
Cc:
"cmis@lists.oasis-open.org" <cmis@lists.oasis-open.org>
Date:
12/06/2013 06:31 AM
Subject:
Re: [cmis] CMIS Extension Proposal: Content Hash Property
Sent by:
<cmis@lists.oasis-open.org>
hi Florian,
Great idea to add a hash!
One thought I had on the hash proposal was that it may make sense for this to be a multi-value property, to support more variety in the client's choice of hash which not always match the server's one choice.
The behaviour of hash when using appendContentStream should be described. Probably it ends being a server implementation choice whether to recompute the hash on each chunk or only when isLastChunk=true. While appending is happening (until isLastChunk=true) the value of cmis:contentStreamHash may then become "not set".
I assume when deleteContentStream happens, the value of cmis:contentStreamHash becomes "not set"?
Instead of the structured format {<hash algorithm>}<hash value>, could we instead adopt some JSON object format like {<hash algorithm>:<hash value>}. Or would that be too weird for AtomPub clients?
One thought on the process for extensions is to always have a jira ticket for the proposal and then we can use Jira commenting instead of the list?
tx!
Greg
On 6 December 2013 06:47, Mr. Florian Mueller <florian.mueller02@sap.com> wrote:Hi,
I've uploaded a proposal [1] for a CMIS feature extension (as defined in the CMIS 1.1 specification).
I would like to discuss it for two reasons. First of all, it would be good to have an optional property that provides the hash value of the document content. But I would also like to use this proposal to start a discussion about a template for such feature extension specifications.
Thanks,
Florian
[1] https://www.oasis-open.org/apps/org/workgroup/cmis/download.php/51648/cmis-extension-content-hash.pdf
--
Greg Melahn | Principal Software Architect
o +1 919 656 9717 | m +1 919 656 9717 | skype gregory.melahn
Greg Melahn | Principal Software Architect
o +1 919 656 9717 | m +1 919 656 9717 | skype gregory.melahn