On 1/21/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
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.
Trustin, I agree, I would remove the register(MessageDecoder) method
and maybe even the register(Class) method.
(and add javadoc for the remaining register methods)
I recently started upgrading my app to mina-2.0-snapshot. When you
have to implement
a fairly simple protocol, MINA offers a lot of choices:
* implement a ProtocolEncoder/Decoder from scratch
* inherit from CumulativeProtocolDecoder
* use DemuxingProtocolCodecFactory, with its 3 methods to register decoders
...
I think this can be a bit overwhelming for newbies.
IHMO sometimes less choice is better.
Maarten
