I'd support making Framed transport the default. I don't think we should entirely remove/deprecate the non-framed transports, as they do offer a tangible benefit when transporting very large/complex data structures via thrift.
Framing requires buffering the entire message in application space, and no data can be passed through to the system's TCP buffer until the entire message length is determined. When framing is not required, a buffered transport enables you to start getting data down into the TCP buffer as soon as its ready to be sent. Granted, the benefit this creates is only applicable in the extreme edge case where you are dealing with very large buffers and are hyper-sensitive to performance. So moving TFramed be the simple out-of-the-box default that no one has to ever think or worry about (and making non-Framing a specific option that power users can hack up at their own peril) seems reasonable to me. -----Original Message----- From: Jonathan Ellis [mailto:[email protected]] Sent: Thursday, November 05, 2009 12:25 PM To: [email protected] Subject: Re: java and twisted python compatibility? On Thu, Nov 5, 2009 at 2:09 PM, Esteve Fernandez <[email protected]> wrote: > I'd be in favor of deprecating the non-framed transports, it's a bit weird > that developers have to foresee whether their servers will be accessed by > framed or non-framed clients. +1
