Why is it ad-hoc? And it uses a factory pattern and I don't think it hard once you get a hang of it. Consumers of the system are not even going to know about these details. Personally I am never a fan of fixing anything that is not broken - in this case it has been working really well for us. This is now just a matter of what one might prefer. Thrift is something that I would not like to see anywhere apart from the entry point. With regards to the using the string to lookup the handlers it was done because if you don't do that then you will have to resort to RPC style instead of message passing or find the handlers based on the kind of messages i.e if-else branching. We use non-blocking I/O for all our internal messaging and Thrift using blocking I/O. There is big difference in throughput and also Thrift non-blocking I/O from what I hear is horrendous in performance and stability. My friend you don't have my vote for this :). Avinash
On Sat, Mar 28, 2009 at 8:11 AM, Jonathan Ellis <[email protected]> wrote: > we have a Message class that mostly represents a bunch of bytes (but > sometimes does not, which in some cases causes bugs) and a bunch of > other *Message classes that are not Message subclasses but generate > Message objects (so you have the amusingly redundant Message message = > readResponseMessage.makeReadResponseMessage() in places). > > I think we can replace these ad-hoc and tedious-to-write Message > factories with generated thrift code. Thrift is good at this and > efficient (currently our message identifiers are inefficient strings > like "ROW-READ-VERB-HANDLER"). > > Any objections to investigating replacing the hand-coded messages with > thrift? >
