no possibility to overload MAX_LENGTH in txjsonrpc.netstring.jsonrpc.QueryProtocol

[Kitlbast]

Hi,

I using Netstring protocol for data transfer. In my JSON-RPC server I can set maxLength to post max data length I need. However, I was wondered that cannot receive data I post to my server. The problem located in QueryProtocol class which inherited from NetstringReceiver but can't overload its MAX_LENGTH variable. Please, add possibility to set this max length size in txjsonrpc.netstring.jsonrpc.Proxy.

[Duncan McGreggor (oubiwann)]

Kitblast,

Thanks for the feature request!

I've committed the change to trunk, and you can see it in the bzr revision 44. This code will be part of the 0.3 txJSON-RPC release, scheduled to come out this week sometime.

Your request brings up a bit of a tricky problem, since MAX_LENGTH is a class attribute in the . If you set it to one thing on one method call, it's going to be set for all instances that are created after that (in the same process). As a result, simply passing an override value will end up creating more problems than it solves.

The way around this takes two steps:

1. Users/developers create a subclass of the QueryFactory, overriding any class attributes or methods they want to, and then
2. Pass the subclass when creating a Proxy or when calling Proxy.callRemote.

I have added support for #2 so that now you can do #1 and get what you need :-) Here are some example usages:

1. On a per-call basis:

class MyFactory(QueryFactory):
    MAX_LENGTH = 1234

proxyInstance.remoteCall(method name, arg1, arg2..., factoryClass=MyFactory)

2. On a per-instance basis:

class MyFactory(QueryFactory):
    MAX_LENGTH = 1234

proxyInstance = Proxy(host, port, factoryClass=MyFactory)

This will set the default maxLength for all calls to 1000. Not that an override at the method-level supersedes an override at the instance-level.

[Duncan McGreggor (oubiwann)]

Woops, bad typo. The last sentence in the previous comment should read:

"Note that an override at the method-level supersedes an override at the instance-level."

[Duncan McGreggor (oubiwann)]

This fix has now been released :-)