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/jsonrpc.py#L63-L64,
> 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