Hi Duncan, <div><br></div><div>Thanks for the response.</div><div><br></div><div>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:<div>
<br></div><div>* 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.</div>
<div><br></div><div>* 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.</div>
<div><br></div><div>* Keyword arguments are not supported (but are allowed by 2.0 spec). I don't think this would be too hard to add.</div><div><br></div><div>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.).</div>
<div><br></div><div>Matthew<br><br><div class="gmail_quote">On Fri, Feb 1, 2013 at 2:30 PM, Duncan McGreggor <span dir="ltr"><<a href="mailto:duncan.mcgreggor@gmail.com" target="_blank">duncan.mcgreggor@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Jan 31, 2013 at 7:43 AM, Matthew Williams <<a href="mailto:mgwilliams@gmail.com">mgwilliams@gmail.com</a>> wrote:<br>
> I have a couple questions regarding txjsonrpc<br>
> (<a href="https://github.com/oubiwann/txjsonrpc/" target="_blank">https://github.com/oubiwann/txjsonrpc/</a>) in connection with the recent<br>
> addition of version 2.0 support.<br>
><br>
> * How complete is the version 2.0 support? I had actually tried some years<br>
> ago to add v2.0 support, but gave up due to some issues I no longer fully<br>
> recall. Are there any known issues with the present implementation?<br>
><br>
> * I noticed that all results are wrapped in an array (see netstring version<br>
> at<br>
> <a href="https://github.com/oubiwann/txjsonrpc/blob/master/txjsonrpc/netstring/jsonrpc.py#L63-L64" target="_blank">https://github.com/oubiwann/txjsonrpc/blob/master/txjsonrpc/netstring/jsonrpc.py#L63-L64</a>,<br>
> but the web implementation has the same code.). This seems odd, as a jsonrpc<br>
> result can be any valid json value, including a string, integer, array, or<br>
> dict. The result is that on the client end, what I return from the function<br>
> call as {"a": "b"} is received as [{"a": "b"}]. Is there some reason for<br>
> this? Would a patch altering this behavior (perhaps optionally) be accepted?<br>
<br>
</div></div>Absolutely!<br>
<br>
Be sure that your patch wouldn't break existing functionality (for<br>
those that depend upon it) with unit tests for both cases.<br>
<br>
Thanks,<br>
<br>
d<br>
</blockquote></div><br></div></div>