uhm. The "problem" is that even though every jsonrpc interface I worked with was parameter-based, for jsonrpc2 position-based and parameter-based are both valid.
On Tuesday, December 11, 2012 10:42:06 PM UTC+1, Jonathan Lundell wrote: > > On 11 Dec 2012, at 1:09 PM, Niphlod <[email protected] <javascript:>> > 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. >>>> >>>> >>>> >>>> >>> > -- > > > > > > > --
