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.mcgreg...@gmail.com > wrote: > On Thu, Jan 31, 2013 at 7:43 AM, Matthew Williams <mgwilli...@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 >
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
