On Nov 27, 2009, at 7:59 PM, Ashish wrote:
Have started looking into the FilterChain implementation and here
are
some initial thoughts
1. Rename IoFilterChain as IoChannel - it gives a more clear picture
and is easy to understand like imagine as a Channel with multiple
stages aka IoFilters.
This came while I was drawing on paper to design something.
2. Have captured a couple of API's that are core to IoChannel
IoSession getSession();
IoFilter getHead();
IoFilter getNextFilter(IoFilter currentFilter);
List<IoFilter> getAll();
void addFilter(String name, IoFilter filter);
void addAfter(String baseName, String filterName,
IoFilter filter);
void removeFilter(String filterName);
My Mina is a bit rusty so my comments may be a bit off base. I would
simplify this to
List<IoFilter> getChain()
Where one can re/move items in the chain.
I would remove the filter name parameter since this is an aspect of
the
filter and not its role in the chain.
This thought did crossed my mind :-)
What we end up with is nice and clean and we leverage the well
known class
List and its iterators. As a matter of fact, I might toss out the
chain
class all together and just have
interface IoSession {
List<IoFilter> getChain();
}
Hmm.. but we create a chain for an Acceptor or Connector, so very much
doubt that chain class will be gone altogether. Once the app goes in
action, we can modify it at runtime, as it gets associated with a
Session
I think that the above paragraph does not support the the need for a
chain class; though there may be something implied that I am not aware
of.
I guess the point that I'm trying to make is that all these
convenience classes and methods add noise. It makes it difficult to
grasp the API when we write our own classes when perfectly good base
classes already exist, e.g. Future<> and LinkedList<>.
Regards,
Alan
