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
