One point of clarification -- I don't understand why looking up by string is better than using an enum, for instance. java will autobox enums for use in a hashmap lookup.
On Sat, Mar 28, 2009 at 10:34 AM, Avinash Lakshman <avinash.laksh...@gmail.com> wrote: > 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 <jbel...@gmail.com> 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? >> >
