[Twisted-Python] txjsonrpc
I have a couple questions regarding txjsonrpc ( https://github.com/oubiwann/txjsonrpc/) in connection with the recent addition of version 2.0 support. * How complete is the version 2.0 support? I had actually tried some years ago to add v2.0 support, but gave up due to some issues I no longer fully recall. Are there any known issues with the present implementation? * I noticed that all results are wrapped in an array (see netstring version at https://github.com/oubiwann/txjsonrpc/blob/master/txjsonrpc/netstring/jsonrp..., but the web implementation has the same code.). This seems odd, as a jsonrpc result can be any valid json value, including a string, integer, array, or dict. The result is that on the client end, what I return from the function call as {"a": "b"} is received as [{"a": "b"}]. Is there some reason for this? Would a patch altering this behavior (perhaps optionally) be accepted? Thanks in advance for any help on these two questions. Matthew Williams
On Thu, Jan 31, 2013 at 4:43 PM, Matthew Williams <mgwilliams@gmail.com>wrote:
I have a couple questions regarding txjsonrpc ( https://github.com/oubiwann/txjsonrpc/) in connection with the recent addition of version 2.0 support.
* How complete is the version 2.0 support? I had actually tried some years ago to add v2.0 support, but gave up due to some issues I no longer fully recall. Are there any known issues with the present implementation?
Not that I know of.
* I noticed that all results are wrapped in an array (see netstring version at https://github.com/oubiwann/txjsonrpc/blob/master/txjsonrpc/netstring/jsonrp..., but the web implementation has the same code.). This seems odd, as a jsonrpc result can be any valid json value, including a string, integer, array, or dict. The result is that on the client end, what I return from the function call as {"a": "b"} is received as [{"a": "b"}]. Is there some reason for this? Would a patch altering this behavior (perhaps optionally) be accepted?
Huh, that's weird. I knew the params had to be an array in some version of JSONRPC (although this limitation appears to have been lifted right now). I can't find anything like that in the spec, so I do wonder why that was ever added :)
Thanks in advance for any help on these two questions.
Matthew Williams
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-- cheers lvh
In that case, should there be a patch that skips that for v2? Or perhaps just raise an error for versions < v2 if the function does not return a list? Of course, this wouldn't be backwards compatible which might be problematic. On Thu, Jan 31, 2013 at 1:45 PM, Laurens Van Houtven <_@lvh.cc> wrote:
On Thu, Jan 31, 2013 at 4:43 PM, Matthew Williams <mgwilliams@gmail.com>wrote:
I have a couple questions regarding txjsonrpc ( https://github.com/oubiwann/txjsonrpc/) in connection with the recent addition of version 2.0 support.
* How complete is the version 2.0 support? I had actually tried some years ago to add v2.0 support, but gave up due to some issues I no longer fully recall. Are there any known issues with the present implementation?
Not that I know of.
* I noticed that all results are wrapped in an array (see netstring version at https://github.com/oubiwann/txjsonrpc/blob/master/txjsonrpc/netstring/jsonrp..., but the web implementation has the same code.). This seems odd, as a jsonrpc result can be any valid json value, including a string, integer, array, or dict. The result is that on the client end, what I return from the function call as {"a": "b"} is received as [{"a": "b"}]. Is there some reason for this? Would a patch altering this behavior (perhaps optionally) be accepted?
Huh, that's weird. I knew the params had to be an array in some version of JSONRPC (although this limitation appears to have been lifted right now). I can't find anything like that in the spec, so I do wonder why that was ever added :)
Thanks in advance for any help on these two questions.
Matthew Williams
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-- cheers lvh
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
It appears that even 1.0 spec (http://json-rpc.org/wiki/specification) allows for non-array result values. Maybe there was a confusion with the fact that in v1 only a list is valid for the request parameters. On Thu, Jan 31, 2013 at 2:04 PM, Matthew Williams <mgwilliams@gmail.com>wrote:
In that case, should there be a patch that skips that for v2? Or perhaps just raise an error for versions < v2 if the function does not return a list? Of course, this wouldn't be backwards compatible which might be problematic.
On Thu, Jan 31, 2013 at 1:45 PM, Laurens Van Houtven <_@lvh.cc> wrote:
On Thu, Jan 31, 2013 at 4:43 PM, Matthew Williams <mgwilliams@gmail.com>wrote:
I have a couple questions regarding txjsonrpc ( https://github.com/oubiwann/txjsonrpc/) in connection with the recent addition of version 2.0 support.
* How complete is the version 2.0 support? I had actually tried some years ago to add v2.0 support, but gave up due to some issues I no longer fully recall. Are there any known issues with the present implementation?
Not that I know of.
* I noticed that all results are wrapped in an array (see netstring version at https://github.com/oubiwann/txjsonrpc/blob/master/txjsonrpc/netstring/jsonrp..., but the web implementation has the same code.). This seems odd, as a jsonrpc result can be any valid json value, including a string, integer, array, or dict. The result is that on the client end, what I return from the function call as {"a": "b"} is received as [{"a": "b"}]. Is there some reason for this? Would a patch altering this behavior (perhaps optionally) be accepted?
Huh, that's weird. I knew the params had to be an array in some version of JSONRPC (although this limitation appears to have been lifted right now). I can't find anything like that in the spec, so I do wonder why that was ever added :)
Thanks in advance for any help on these two questions.
Matthew Williams
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-- cheers lvh
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Thu, Jan 31, 2013 at 7:43 AM, Matthew Williams <mgwilliams@gmail.com> wrote:
I have a couple questions regarding txjsonrpc (https://github.com/oubiwann/txjsonrpc/) in connection with the recent addition of version 2.0 support.
* How complete is the version 2.0 support? I had actually tried some years ago to add v2.0 support, but gave up due to some issues I no longer fully recall. Are there any known issues with the present implementation?
* I noticed that all results are wrapped in an array (see netstring version at https://github.com/oubiwann/txjsonrpc/blob/master/txjsonrpc/netstring/jsonrp..., but the web implementation has the same code.). This seems odd, as a jsonrpc result can be any valid json value, including a string, integer, array, or dict. The result is that on the client end, what I return from the function call as {"a": "b"} is received as [{"a": "b"}]. Is there some reason for this? Would a patch altering this behavior (perhaps optionally) be accepted?
Absolutely! Be sure that your patch wouldn't break existing functionality (for those that depend upon it) with unit tests for both cases. Thanks, d
Hi Duncan, Thanks for the response. I'm certainly open to suggestions otherwise, but it seems patching txjsonrpc to do the following would be rather involved. I started working on some of this and realized maintaining backwards compatibility might be very difficult: * Persistent TCP connections across requests. At first I thought I could just add an additional Proxy and Factory. Unfortunately the BaseProxy and BaseFactory expect a new connection for each request, so this started getting quite involved and would have either require extensive changes to all the transports, or a parallel implementation. * The array issue is a bit strange. The only solution I could think of would be to add a "wrap_results" keyword or some such to the Proxy constructor (both client and server, as I think the client compensates for the array wrapper). It would have to default to True for backwards compatibility. * Keyword arguments are not supported (but are allowed by 2.0 spec). I don't think this would be too hard to add. I'm on the fence as to whether to attack these issues in txjsonrpc, or to revert to my 2.0/netstrings only implementation, which itself needs a lot of work (the code is far from ideal, there are no tests, etc.). Matthew On Fri, Feb 1, 2013 at 2:30 PM, Duncan McGreggor <duncan.mcgreggor@gmail.com
wrote:
On Thu, Jan 31, 2013 at 7:43 AM, Matthew Williams <mgwilliams@gmail.com> wrote:
I have a couple questions regarding txjsonrpc (https://github.com/oubiwann/txjsonrpc/) in connection with the recent addition of version 2.0 support.
* How complete is the version 2.0 support? I had actually tried some years ago to add v2.0 support, but gave up due to some issues I no longer fully recall. Are there any known issues with the present implementation?
* I noticed that all results are wrapped in an array (see netstring version at
https://github.com/oubiwann/txjsonrpc/blob/master/txjsonrpc/netstring/jsonrp... ,
but the web implementation has the same code.). This seems odd, as a jsonrpc result can be any valid json value, including a string, integer, array, or dict. The result is that on the client end, what I return from the function call as {"a": "b"} is received as [{"a": "b"}]. Is there some reason for this? Would a patch altering this behavior (perhaps optionally) be accepted?
Absolutely!
Be sure that your patch wouldn't break existing functionality (for those that depend upon it) with unit tests for both cases.
Thanks,
d
participants (3)
-
Duncan McGreggor -
Laurens Van Houtven -
Matthew Williams