[Twisted-Python] txjsonrpc

Matthew Williams mgwilliams at gmail.com
Fri Feb 1 14:49:19 EST 2013

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

* 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.).


On Fri, Feb 1, 2013 at 2:30 PM, Duncan McGreggor <duncan.mcgreggor at gmail.com
> wrote:

> On Thu, Jan 31, 2013 at 7:43 AM, Matthew Williams <mgwilliams at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://twistedmatrix.com/pipermail/twisted-python/attachments/20130201/4a8f6fc7/attachment.htm 

More information about the Twisted-Python mailing list