Hi guys,
we discussed a bit about this IoBuffer thing I'm working on with Julien
today.
It seems that we don't need an acumulating buffer anywhere but in the
decoder (all in all, we don't expect the filters to use an IoBuffer in
the messageReceined() method. It's expecting an Object. This Object is
cast to a ByteBuffer only when processed by the decoder).
So we may want to make this class a hidden one for the common user,
except for those who want to write their own decoder.
The selector will always store the incoming data into a ByteBuffer, and
propagate it as is into the chain (that raises an other question : why
do we reuse one single ByteBuffer for that purpose? We may want to coy
this data into a separate buffer. Also the buffer *must* be associated
with the current session, not with the selector, otherwise we won't be
able to process more than one session at a time (assuming we may have an
executor somewhere down the chain)).
I would suggest that the selector copy the read data into the session's
buffer (which size should be configurable), and then passed into the
chain. When the decoder try to process the incoming message, we can
cumulate the BB ino the BufferList class...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
