On Apr 3, 2009, at 2:30 AM, Garrett Smith wrote:
Unless your connections are long running -- to the point that you
*really* need to support thousands of concurrent connections (this is
very rarely the case with HTTP as you soon become CPU bound), I'd
stick
with threads -- async can be a serious pain, esp if it starts leaking
into your app (coroutines, Twisted deferreds, etc.)
Thanks Garrett. That sounds like good advice. Perhaps I will take
this advice until I learn that I really do have very special needs for
my service. I'm prematurely optimizing I suppose (in hopes of getting
it right the first time).
Auth in Thrift would be wonderful but I wonder if that's feature
creep?
Yes, definite is. I've been looking at AMQP and their authentication
scheme, using SASL, is quite simple and still useful. This could serve
possibly as a model for Thrift. Maybe this has been hashed out
before and
duly rejected though.
I'm not familiar so I looked it up; I suppose you mean this?
http://jira.amqp.org/confluence/display/AMQP/Authentication
There's a lot of back-and-forth chatter there to setup the
connection. This kind of thing has always struck me as "too
much" (sure, the same sort of thing happens in setting up a SSL
connection) for simply making one-off requests like a RPC. But then
again, not everyone is making one-off RPCs I suppose so the connection
overhead is justified in various cases.
Thanks,
Brian