I took some time to watch at the jsonrpc specs. Right now I had experience
with jsonrpc only in the "named parameters" format. I thought it was the
standard, my bad.
However, I found out that 2.0 introduced "named parameters" that were not
supported - explicitely - in 1.0
--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}
--> {"jsonrpc": "2.0", "method": "subtract", "params": {"subtrahend": 23,
"minuend": 42}, "id": 3}
<-- {"jsonrpc": "2.0", "result": 19, "id": 3}
are both valid.
Maybe revert this and make a jsonrpc2 decorator to support named parameters
explicitely would be a better solution?
On Tuesday, December 11, 2012 9:57:50 PM UTC+1, Kurt Grutzmacher wrote:
>
> I don't think this is a good JSON-RPC example as the change broke our app
> that uses simplejsonrpc or jsonrpclib to make API calls.
>
> Based on the jsonrpclib python module @
> https://code.google.com/p/jsonrpclib/ requests look like:
>
> >>> import jsonrpclib
> >>> server = jsonrpclib.Server('http://localhost:8080')
> >>> server.add(5,6)
> 11
> >>> print jsonrpclib.history.request
> {"jsonrpc": "2.0", "params": [5, 6], "id": "gb3c9g37", "method": "add"}
> >>> print jsonrpclib.history.response
> {'jsonrpc': '2.0', 'result': 11, 'id': 'gb3c9g37'}
>
>
> And the JSON-RPC spec states params should be "An Array of objects to pass
> as arguments to the method." -- http://json-rpc.org/wiki/specification
>
> However the actual spec doesn't specify array, dict or whatever as it
> tries to be universal: "A Structured value that holds the parameter
> values to be used during the invocation of the method. This member MAY be
> omitted." http://www.jsonrpc.org/specification#request_object
>
> For simplejsonrpc and jsonrpclib to work we have to undo this change in
> gluon/tools.py
>
>
> On Wednesday, November 14, 2012 1:25:22 PM UTC-8, Mike Anson wrote:
>>
>> Thanks very much for your help Niphlod.
>>
>> On Wednesday, 14 November 2012 16:10:35 UTC-5, Niphlod wrote:
>>>
>>>
>>> Yes I understand your point. The reason it is currently like this is
>>>> because if I use your suggestion (which I obviously had originally)
>>>>
>>>> {"id": 1, "method": "savemessage", "params": { "*message*":
>>>> "variableholdingmessage", "*uid*" : "variableholdingmail"}}
>>>>
>>>> I get message and uid as the values in the DB. So I switched them.
>>>>
>>>> {"id": 1, "method": "savemessage", "params": {
>>>> "variableholdingmessage": "mymessage", "variableholdinguid" :
>>>> "myemail@localhost"}}
>>>>
>>>> The result means that variableholdingmessage is saved as the message
>>>> and not the expected "mymessage". Exactly the same for uid.
>>>>
>>>> Unfortunately jsonrpc call method has a bug. in web2py 2.2.1, in
>>> gluon/tools.py, line 4231 should be
>>>
>>> s = methods[method](**params)
>>>
>>> instead of
>>>
>>> s = methods[method](*params)
>>>
>>>
>>> sending a patch to Massimo right now!
>>>
>>>
>>>>
>>>> re: PS -- haha yes I know. I did try it with single quotes and it
>>>> crapped out?? So just kept the doubles. It's not that bad!
>>>>
>>>> re: PS2 -- have you any recommendations to solve this special character
>>>> potential problem?
>>>>
>>>>
>>> Normally with jsonrpc you use something that is not curl, e.g. a
>>> programming language that supports json (python?!)
>>> Escaping on bash without awk, sed, etc is always problematic.... but if
>>> you're willing to have as only limitation the " character that is less
>>> frequent to use within a message, why don't you use one of the methods not
>>> requiring a json body to be posted ? e.g. @service.xml, @service.csv or
>>> @service.json....
>>>
>>> curl -v --get --data-urlencode \"uid=$uid\" --data-urlencode
>>> \"message=$message\" $url
>>>
>>> here curl takes care of urlencoding the message and the uid parameters.
>>>
>>>
>>>
>>>
>>
--
