From: Marcelo V. <va...@us...> - 2009-09-10 23:02:37
|
On Thu, Sep 10, 2009 at 3:09 PM, Dale Anson <da...@gr...> wrote: > 1. All EBComponents get sent every message, regardless of whether > they care about all those messages. Usually, an EBComponent only > cares about one or two message types. I like the concept but I don't know if I like your planned execution (or what I understand of it). From what I understood, the plugin would get the messages it subscribed to, but still would have to multiplex them (today using instanceof to check the type). What if instead of doing subscription this way this was done more dynamically using reflection? A quick idea of how to do it: create a convention that any method called "handleMessa ge" (or "handleEBMessage" if the former is too generic) is targeted at handling an EBMessage. When dispatching messages, the code checks the sink for a specific method matching the incoming message type (e.g., if the incoming type is "ViewUpdate", the dispatcher looks for "handleEBMessage(ViewUpdate)"). If a handler is not found, it looks for a generic "handleEBMessage(EBMessage)" method. If no handler is found, just ignore that sink. The dispatcher could cache the type -> handler mappings if reflection is too expensive. The only issue there is that, since EBComponent is an interface and not a class, flushing the cache might be tricky since we can't keep it in a base class. (Or maybe not, maybe it's as easy as doing it when the EBComponent is removed from the bus). This doesn't cover the event's "what" multiplexing that Shlomy mentions, but I think it is a cleaner approach than your subscription model. It could also have problems with class loaders getting confused (similar to the instanceof issues you mention, although I've never seen them), but if that happens I think it's a lower level issue with the class loaders that we should fix. -- Marcelo Vanzin mmv...@gm... "Life's too short to drink cheap beer." |