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
