On 11 Dec 2012, at 1:09 PM, Niphlod <niph...@gmail.com> wrote:
> 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?
How about both jsonrpc1 and jsonrpc2, and then jsonrpc = jsonrpc2? (I think
it'd be better to make v2 the default.)
>
> 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.
>
>
>
>
> --
>
>
>
--
