You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Michael Brackx <mi...@gmail.com> on 2015/10/06 16:59:44 UTC

browser binding java client

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

Re: browser binding java client

Posted by Florian Müller <fm...@apache.org>.
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