On 1/17/07, Steven E. Harris <[EMAIL PROTECTED]> wrote:

Trustin Lee <[EMAIL PROTECTED]> writes:

> Users are supposed to put a message header (or prefix) detection (or
> recognition) code in decodable(), and to put the code that reads the
> actual data fields (or message body) in decode().

I recall being confused by the example (it may not have been this same
example) because there was some duplication of parsing steps in
decodable() and decode(). I wondered, why do all this parsing work in
decodable() only to repeat it later in decode()?


It's probably my mistake.  Could you let me know where did you find such a
problem so I can fix it?  :)



With that question in mind, if decodable() returns
MessageDecoderResult.OK, is it safe for the decoder to cache any
parsed "header data" for a subsequent call to decode()? That is, can
the decoder assume that the next call it will receive for a given
session after decodable() is decode() for the same message?


Yes.  But 'where to store' highly depends on how you registered your
MessageDecoder implementation to DemuxingProtocolCodecFactory.  If it's
added via register(MessageDecoder), you will have to store all state
information as session attribute.  If it's added via register(Class) or
register(MessageDecoderFactory), then it's fine to store the state
information as a member field.  This sometimes causes confusion, so I wonder
just removing register(MessageDecoder) might be a better choice.

HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

Reply via email to