Hi Rob, On 7/27/07, Rob Butler <[EMAIL PROTECTED]> wrote:
I use messageSent to close the IoSession after sending a client response. This is ideal for servers where the normal interaction is connect->request->response->close. It allows the session management logic to be cleanly separated from the request/response logic. It is also helpful when the decision to close the session or not depends on some advanced logic. This could be wrapped into an IoFutureListener instead if necessary.
Such a behavior could be simplified like the following unless you have additional logic: session.write(response).addListener(IoFutureListener.CLOSE);
I think the biggest reason for not removing the messageSent event is it takes away from the simplicity of MINA. One could argue that if you remove messageSent you should also remove sessionClosed, because you can just add an IoFutureListener when you close the session. With the filter chains that MINA supports placing logic "up" the chain is pretty easy. You could have a filter 4 levels "up" from where your logic is to send a message doing something with that sent message, or just counting it, etc. What about SSLFilter, doesn't it use messageSent?
sessionClosed() cannot be removed because the remote peer can close the connection instead of your close request. SSLFilter doesn't use messageSent event. It just contains trivial event filtering which can be removed if messageSent didn't exist. I think we need to find more concrete use case for messageSent event, because just counting can also be done with an IoFutureListener (or we already have the property in IoSession.) Please let me know whenever you find a good example use.
Instead, if you leave messageSent people have a choice. They can either use messageSent, or add an IoFutureListener as your suggesting.
I want to leave messageSent as it is if it doesn't hurt the IoFilter implementors. Current IoFilter implementation becomes quite complicated when you perform transformation. Or should we just provide an abstract IoFilter implementation that helps transformation? The number of transformation filters might not that many as we expect. It's an open discussion and nothing's decided yet. I'd like to find out the best solution every community member satisfies in the extent that doesn't hurt the framework. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
