[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
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
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
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
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
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 wrote: On Thu, Jan 31, 2013 at 7:43 AM, Matthew Williams 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