Hi,
My arguments to keep messageSent() method are:
1. It is more flexable to write:
messageSent( IoFilter.NextFilter nextFilter, IoSession session,
Object message. ) {
// some checking logic with sent message, session attributes, ...
session.close().join();
}
then:
session.write(response).addListener(IoFutureListener.CLOSE);
2. Both messageSent() and sessionClosed() can be used to do certain
management and monitoring operation, including counting, internal
state transfering or clean-up, depending on either persistent
connection or single request-response based connection.
Keep both messageSent() and sessionClose() in IoFilter, they can
easily share some internal methods/state in one IoFilter class or
instance.
My 2 cents.
Jian
On 7/26/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
> 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
>
