chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Potts <jeffpott...@gmail.com>
Subject Discussion on supporting JSON posts in browser binding
Date Tue, 29 Nov 2011 20:43:51 GMT
Fellow Chemists,

Florian and I were having this conversation off-list, and I thought it would probably make
sense to open it up to the wider audience. I realize this is being discussed amongst the OASIS
TC, but thought it would be good to get additional CMIS developers to weigh in.

The discussion is regarding the browser binding and whether or not it should be JSON both
ways. Currently, the proposal [1] specifies JSON only to be sent from the server as the result
of a get. Any creates and updates happen through HTML form posts. 

Jeff

[1] http://tools.oasis-open.org/version-control/svn/cmis/trunk/BrowserBinding/specification/cmis-spec-v0.5-browserbinding.doc

--------------------------
Hi Jeff,

Here are examples how the data of an updateProperties() call would look like in Python.


URL encoded:

data = {
'cmisaction': 'updateProperties',
'propertyId[0]': 'cmis:name',
'propertyValue[0]': 'test.txt'
}


JSON encoded:

data = {
'cmisaction': 'updateProperties',
'data': { 'properties':
           [ 'cmis:name': { 'id': 'cmis:name', 'value': 'test.txt' } ]
       }
}


I can't see where JSON is easier.

The OpenCMIS client API is also asymmetric for a good reason. When you retrieve data, you
usually want to get all kinds of details (property id, value, data type, query name, cardinality,
etc.). When you send data you only want to provide the bare minimum - a property id and a
value. The overhead in the AtomPub binding that is necessary to send data is enormous. We
shouldn't repeat that mistake.

Apart from that, when document content has to be attached and the request must be a multipart
message, URL encoded parameters are support by basically all HTTP libraries. JSON payload
is not.


Florian



On 08/11/2011 00:44, Jeff Potts wrote:
> To me, it seems more natural. Get JSON out, put JSON back in. And if I
> wanted to implement the JSON binding in cmislib, it would be much easier
> for me to move JSON back and forth because I can convert JSON back and
> forth between JSON and Python objects easily. If I have to stop and
> convert everything from an object into an HTML form before I post it,
> that seems unnatural and extra work.
> 
> It also seems more parallel to the ATOM PUB binding. A GET returns XML
> and I can then tweak that XML and POST it right back. Seems like I
> should be able to do that with JSON.
> 
> Jeff
> 
> On Nov 7, 2011, at 8:44 PM, Florian Müller wrote:
> 
>> Hi Jeff,
>> 
>> I saw your tweet about the browser binding. Could you explain why do
>> you think that we need JSON when POSTing to a CMIS repository?
>> 
>> The current spec draft defines that POST parameters must be
>> form-urlencoded. That is faster on the client side, it is faster to
>> parse on the server side and more compact on the wire than JSON.
>> Furthermore, it supported out-of-the-box by all HTTP libraries out
>> there. You don't need a JSON library for that.
>> 
>> We have to support form-urlencoded requests for JavaScript clients in
>> the browser. Adding a second request format would increase the burden
>> to implement the binding.  
>> 
>> 
>> 
>> Cheers,
>> 
>> Florian

Mime
View raw message