chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Monks <>
Subject Re: AtomPub / setContentStream: How to efficiently determine new cmis:objectId after update on versioned cmis:document?
Date Wed, 18 Jun 2014 22:32:03 GMT
Thanks Florian - that confirms my analysis.  I’ve raised a bug report<>
[1] against the specification for this.



On 2014-06-18, at 3:14 PM, Florian Müller <<>>

Hi Peter,

There is no standardized way and therefore OpenCMIS doesn't do it.
However, it is not impossible. The server must send a Location header in
the response of a setContentStream request. The value of this header is
a URL, which contains the new object ID.
The problem is that the pattern of this URL is not standardized. If you
know the server implementation and the URL pattern, you can extract the
object ID. If you don't know the pattern the best you can do is guessing.
But that is not implemented in OpenCMIS and hidden from the application.
We could implement some heuristics here, but that would never be 100%
reliable for all servers.

- Florian


I realise this is a general CMIS question, but the TC doesn’t provide a general purpose
Q&A / discussion mailing list, and this seems to be the nearest thing.

Section 3.1.9 of the CMIS 1.1 specification states that the AtomPub version of the setContentStream
service doesn't return the cmis:objectId of the new version of the document (note: this is
an exception to the domain model, section  The Apache Chemistry library that
I’m using (Java / OpenCMIS) faithfully implements this behaviour.

My question is - how can a CMIS client application efficiently* obtain the new cmis:objectId
value, after setting a new content stream on a versioned cmis:document via AtomPub?

Thanks in advance,

* where "efficiently" means "without further round trips to the CMIS server"

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message