On Nov 29, 2011, at 9:43 PM, Jeff Potts wrote:
> 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' } ]
> }
> }
>
Why not
'data': { 'properties':
[ { '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.
Indeed. But I don't see a contradiction with using a lightweight JSON encoding.
> Apart from that, when document content has to be attached and the request
> must be a multipart message,
Yeah, that's the annoying part.
> URL encoded parameters are support by basically all HTTP libraries. JSON
> payload is not.
All reasonable languages and framework have JSON encoding and decoding now.
D.
>
>
> 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
--
Stefane Fermigier
http://twitter.com/sfermigier - http://www.linkedin.com/in/sfermigier
"Although I suffer from the defeats, I learn to achieve more victories, and
that's the essence of job satisfaction." - Gerald Weinberg
"There's no such thing as can't. You always have a choice." - Ken Gor
