Hi Dan, Re: 1, bidirectional messaging isn't something that Thrift explicitly supports. There are a couple ways you could build this sort of functionality using Thrift.
1/ Have your client also provide a Thrift service. Do some basic negotiation/registration at startup, and then your server can make calls back to the listening client service when events that you care about occur. Basically, you just have 2 services. 2/ Use high timeouts and a COMET style request... basically have your client call server.getEvent() and just block on the server side until the next event occurs. This is a bit hacky but acceptable if you're okay leaving hanging sockets open in your application. There isn't really a clean way to do this with a file-descriptor/poll-based approach on the client. Re: the docs, these are known to be problematic. I'm not sure anyone is explicitly working on them actively at the moment. Cheers, Mark -----Original Message----- From: Ephraim Dan [mailto:[email protected]] Sent: Tuesday, January 06, 2009 6:23 AM To: [email protected] Subject: subscriber model, general doc question Hi! We're seriously considering using thrift for an internal application server in our organization. To this end, I have a couple of questions: 1. One of the things we need is for daemon clients to be able to register for subscriptions to events of certain types, and have the server send events to the client. The client would presumably have a file-descriptor after subscription/registration, and then poll it for events from the server. Correct me if I'm wrong but thrift doesn't appear to have out-of-the-box support for this? Does anyone have recommendations on how this could be achieved without too much effort? 2. Besides #1, thrift *seems* to meet almost all of our needs - except - the docs. Is anyone actively working on this? Thanks! --edan
