Hi Michael,
Here are some answers.
* Re "get the create document response":
That's true for two reasons.
1) Unfortunately, a few repositories send wrong data back - for
whatever reason. The only piece of data you can rely on is the object
ID.
2) The client cannot control what the server should return
(properties, allowable actions, ACL, renditions, etc.).
It would be spec compliant for a repository only to return the
object ID property. A client then has to determine if the returned data
is sufficient and, if not, call getObject() by itself.
For most applications it's more convenient to make another call and
rely on this result. If you want avoid the additional getObject() call,
you can use Session.createDocument().
Nevertheless, we could extend the low-level interface to also make the
returned data available.
* Re "control the content disposition":
That's true, because the content disposition is only relevant for web
browsers. The OpenCMIS API would always provide an InputStream
regardless of the content disposition setting.
For testing, well, we could introduce a session parameter.
* Re "query via http get":
Also true. In contrast to a POST request a GET request can be
restricted in length. I've seen cases where a server rejected long query
strings via GET because the HTTP header buffer on the server side was to
small. (Yes, some people have >8k query strings.)
Of course, we could also offer a session parameter for query GET
calls, but I really wouldn't use that in production.
- Florian
Hi,
As far as i am aware some things are currently not possible with the
java
client.
Please correct me if i am wrong.
This is mainly, but not exclusively, an issue for testing.
Other clients may use this functionality, so it should be testable and
ideally in the TCK.
- get the create document response
The low level api returns the object id. The high level client does a
second request to get the metadata.
- control the content disposition
- query via http get
Michael
