Hi Duncan, <div><br></div><div>Thanks for the response.</div><div><br></div><div>I&#39;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 &quot;wrap_results&quot; 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&#39;t think this would be too hard to add.</div><div><br></div><div>I&#39;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">&lt;<a href="mailto:duncan.mcgreggor@gmail.com" target="_blank">duncan.mcgreggor@gmail.com</a>&gt;</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 &lt;<a href="mailto:mgwilliams@gmail.com">mgwilliams@gmail.com</a>&gt; wrote:<br>

&gt; I have a couple questions regarding txjsonrpc<br>
&gt; (<a href="https://github.com/oubiwann/txjsonrpc/" target="_blank">https://github.com/oubiwann/txjsonrpc/</a>) in connection with the recent<br>
&gt; addition of version 2.0 support.<br>
&gt;<br>
&gt; * How complete is the version 2.0 support? I had actually tried some years<br>
&gt; ago to add v2.0 support, but gave up due to some issues I no longer fully<br>
&gt; recall. Are there any known issues with the present implementation?<br>
&gt;<br>
&gt; * I noticed that all results are wrapped in an array (see netstring version<br>
&gt; at<br>
&gt; <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>
&gt; but the web implementation has the same code.). This seems odd, as a jsonrpc<br>
&gt; result can be any valid json value, including a string, integer, array, or<br>
&gt; dict. The result is that on the client end, what I return from the function<br>
&gt; call as {&quot;a&quot;: &quot;b&quot;} is received as [{&quot;a&quot;: &quot;b&quot;}]. Is there some reason for<br>
&gt; this? Would a patch altering this behavior (perhaps optionally) be accepted?<br>
<br>
</div></div>Absolutely!<br>
<br>
Be sure that your patch wouldn&#39;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>