"이희승 (Trustin Lee) <[EMAIL PROTECTED]>" wrote: > David, you and I discussed about IoBuffer stuff, so let me comment about > other proposed changes... > > Emmanuel Lecharny wrote: >> "이희승 (Trustin Lee) <[EMAIL PROTECTED]>" wrote: >>> 2) Get rid of IoHandler and let IoFilter replace it. >>> >>> IoHandler is just a special IoFilter at the end of the filter chain. I >>> don't see any reason to keep it special considering that we are often >>> building multi-layered protocols. >>> >> I didn't went deep into this class, but if it's just the last part of a >> filter, then it's just a filter like any other, a catch-all filter. So I >> agree with the idea to define it as a IoFilter too. > > The differences between IoHandler and IoFilter are: > > * IoHandler doesn't have life cycle callbacks (onPreAdd, > onPostRemove...) while IoFilter has. > * IoHandler doesn't have handler methods for requests such as write, > setTrafficMask and close while IoFilter has. > > This is why I'm proposing to split IoFilter into multiple interfaces: > > * Interface A which provides handler methods for incoming events. > * Interface B which extends the interface A and provides handler methods > for outgoing requests > * Interface C which extends the interface B and provides lifecycle > management methods > > This inheritance relationship might not be precise. For example, both > interface B and C could extend the interface A directly.
UpstreamFilter and DownstreamFilter sounds somewhat strange. :) What about InputHandler, OutputHandler, IoHandler (extends InputHandler and OutputHandler) and LifecycleAwareHandler? -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/
signature.asc
Description: OpenPGP digital signature
