I actually have to code drivers for several different instruments, all
with the same basic challenges, so I agree that the state machine
solution is the better way to go. This is particularly so because the
message terminators are themselves stateful, so are not easily handled
simply by tweaking the TextLineDecoder.
Again, thank you for your very helpful suggestions.
Adam Fisk wrote:
There's likely an easier way, though, to, like taking the TextLineCodec code
and just tweaking it to also look for ">". My last suggestion is an elegant
way to do it, but it would require much more work.
On 8/12/07, Adam Fisk <email@example.com> wrote:
I'd give the state machine in AsyncWeb a look, as well as some of the
helper classes. The state machine approach takes awhile to wrap your head
around if you're not used to it, but it works well. The
"ConsumeToDynamicTerminatorDecodingState" helper class will do exactly what
you want. You would need to write a fair bit of custom state machine code
for your protocol going this route, but I think it's worth it.
On 8/9/07, Yigal Rachman <firstname.lastname@example.org> wrote:
I have a MINA client that acts as a driver for a scientific instrument.
The communication is via a serial link using ASCII. The messages from
the instrument are usually terminated with a line feed, but are
sometimes terminated with a ">" instead (when it is prompting for
Could you please suggest a design pattern that would do this elegantly
in MINA? I expect it will use the TextLineCodec and possibly some other
filters, but I am fuzzy on the details.
DMAS Data Acquisition Developer
University of Victoria,
Victoria, BC, Canada