I think a numbering scheme could work. The
DefaultIoFilterChainBuilder class represents each filter with an index
internally already. Why not use a similar numbering scheme to order
the filters. It does not have to be 1,2,3. You could use 10,20,30 so
that if you wanted to insert a new filter between 10 and 20, you have
plenty of slots available. We could also expose a method that would
return a filter's id in the chain.
--
..Cheers
Mark
On 4/26/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
On 4/26/07, Mark Webb <[EMAIL PROTECTED]> wrote:
> If the string manipulation/comparison/etc is a problem with using too
> many CPU cycles, could we just just an int or long and give each
> filter an id? This might also aid in the ordering.
> The developer should always know the name or id of a filter, so it
> should not make things any more complex.
Well, using numbers might cause magic number hell. Is there any way
to work around it?
Just giving up storing stuff as session attributes and providing a
dedicated attribute storage per filter per session might be a better
choice. There are disadvantages in this approach. 1) JMX integration
can be more complex because we have one more thing to wrap. 2) Any
existing public session attribute keys that some IoFilters (e.g.
SSLFilter) expose need to change somehow. I think these changes are
not that hard to follow though.
Once we make this change, the use of session attributes will decrease
a lot, because a usual IoHandler implementor will define a class that
stores the state of the session and store the instance of the class as
a session attribute, like the following:
public class ProtocolContext {
public boolean userLoggedIn = false;
public int userStateCode = 0;
}
public void sessionOpened(IoSession session) {
session.setAttribute("ctx", new ProtocolContext());
}
public void messageReceived(IoSession session, Object message) {
ProtocolContext ctx = (ProtocolContext) session.getAttribute("ctx");
....
ctx.userStateCode = ...;
}
Then, what is the advantage of having session attributes over using
multiton handlers? -- http://tinyurl.com/28j4oj
I think we need to think again what session attributes are useful for
if we are not going to use them to store filter states.
Any idea?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
