Uploaded image for project: 'MINA'
  1. MINA
  2. DIRMINA-586

Dynamic delimiter support for TextLineCodecFactory

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Minor
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.0-M1
    • Fix Version/s: 2.0.8
    • Component/s: Filter
    • Labels:
      None

      Description

      TextLineCodecFactory supports static delimiters only. For some cases, users need to switch the delimiter dynamically depending on context. Related discussion is found here:

      http://markmail.org/message/loiqoej35evt2yvv

        Activity

        Hide
        elihusmails Mark Webb added a comment -

        Please let me know if this is still an issue. I believe that if we make a change to the current functionality, it might break current implementations.

        This fix may require a special class, instead of changes to the current implementation.

        Please let me know what you think. I am considering closing this issue and marking as "will not fix"

        Show
        elihusmails Mark Webb added a comment - Please let me know if this is still an issue. I believe that if we make a change to the current functionality, it might break current implementations. This fix may require a special class, instead of changes to the current implementation. Please let me know what you think. I am considering closing this issue and marking as "will not fix"
        Hide
        edwin11 Edwin Lee added a comment -

        i encountered something similar when i was writing a configurable automated client engine for Telnet (i.e. automatically logs in, sends command, collect output, etc). (Seems like OP is also dealing with a Telnet login.)

        IMHO, this isn't exactly just an extension/enhancement of the TextLineCodecFactory (and corresponding TextLineEncoder and TextLineDecoder), though there are overlaps (both are text-based, and both use delimiters, though when dealing with Telnet, you may need more than just delimiters).

        IMHO, to fully handle the dynamic-ness of this, it probably requires a custom implementation of ProtocolDecoder's decode method (i.e. even if a DynamicTextLineDecoder is put in, a hook would be required, and the hook would almost cover the decode method), which is almost as good as a whole new ProtocolDecoder implementation, and hence a new ProtocolCodecFactory implementation (though the TextLineEncoder can probably be reused in this case).

        Show
        edwin11 Edwin Lee added a comment - i encountered something similar when i was writing a configurable automated client engine for Telnet (i.e. automatically logs in, sends command, collect output, etc). (Seems like OP is also dealing with a Telnet login.) IMHO, this isn't exactly just an extension/enhancement of the TextLineCodecFactory (and corresponding TextLineEncoder and TextLineDecoder), though there are overlaps (both are text-based, and both use delimiters, though when dealing with Telnet, you may need more than just delimiters). IMHO, to fully handle the dynamic-ness of this, it probably requires a custom implementation of ProtocolDecoder's decode method (i.e. even if a DynamicTextLineDecoder is put in, a hook would be required, and the hook would almost cover the decode method), which is almost as good as a whole new ProtocolDecoder implementation, and hence a new ProtocolCodecFactory implementation (though the TextLineEncoder can probably be reused in this case).
        Hide
        paliwalashish Ashish Paliwal added a comment - - edited

        Not sure if this is still an issue. A custom delimiter can be created using following construct

        new LineDelimiter("delimiter") ; and passed onto TextLineCodecFactory

        To specify the same in TextLineCodecfactory, following constructors can be used

        public TextLineCodecFactory(Charset charset, String encodingDelimiter, String decodingDelimiter)

        or

        public TextLineCodecFactory(Charset charset, LineDelimiter encodingDelimiter, LineDelimiter decodingDelimiter)

        Show
        paliwalashish Ashish Paliwal added a comment - - edited Not sure if this is still an issue. A custom delimiter can be created using following construct new LineDelimiter("delimiter") ; and passed onto TextLineCodecFactory To specify the same in TextLineCodecfactory, following constructors can be used public TextLineCodecFactory(Charset charset, String encodingDelimiter, String decodingDelimiter) or public TextLineCodecFactory(Charset charset, LineDelimiter encodingDelimiter, LineDelimiter decodingDelimiter)
        Hide
        elihusmails Mark Webb added a comment -

        I vote to close it. If we have functionality to solve the request, then it should be closed.

        Show
        elihusmails Mark Webb added a comment - I vote to close it. If we have functionality to solve the request, then it should be closed.
        Hide
        ted_kods Edouard De Oliveira added a comment -

        In fact, it is not solved
        Being able to specify a custom delimiter at startup is not the same as being able to switch delimiters when context changes

        Show
        ted_kods Edouard De Oliveira added a comment - In fact, it is not solved Being able to specify a custom delimiter at startup is not the same as being able to switch delimiters when context changes
        Hide
        paliwalashish Ashish Paliwal added a comment -

        Hmm... I think I misinterpreted this. I am wondering do we need to have this functionality as part of TextLineCodecFactory. If we do, then how do we determine, when to switch context?
        Pardon my ignorance, but how many implementation shall need such a implementation?

        Show
        paliwalashish Ashish Paliwal added a comment - Hmm... I think I misinterpreted this. I am wondering do we need to have this functionality as part of TextLineCodecFactory. If we do, then how do we determine, when to switch context? Pardon my ignorance, but how many implementation shall need such a implementation?
        Hide
        chase@osdev.org Matthieu Chase Heimer added a comment -

        I don't think modifying the TextLineEncoder or the TextLineCodecFactory is going to be the right approach. I did a quick glance at some of the code and there are some problems that you'd run into. First, there is only a single instance of the TextLineEncoder returned by the TextLineCodecFactory so even though the encoder is stored in the session you end up with all sessions storing a reference to the same encoder. So if you change the delimiter in one session's encoder you'd be changing it for all of them. You'd have to modify the encoder to read the current delimiter out of the session or modify the codecfactory to return different instances of the encoder per session to start with.

        Based on your discussion you need to send messages from the server to the client with and without a linefeed. The "without" part means you want to send text that is not a line. That would seem to be outside the scope of a TextLineEncoder.
        You have a couple of possible solutions.

        1) Don't use the TextLineCodecFactory. It looks like TextLineDecoder is the right decoder for you but TextLineEncoder is the wrong one. Just create a basic text pass-through encoder and have your handler write your messages with/without linefeeds as needed.

        2) The ProtocolCodecFilter looks like it will skip the encoding of the message being written if it is an instance of an IoBuffer. When you need to leave off the linefeed you could bypass the encoder by writing IoBuffer objects.

        3) The ProtocolCodecFilter is pulling the encoder out of the IoSession. On a session by session basis you could swap the TextLineEncoder and a PassThoughEncoder in the session. You could even make a filter that handled the swapping for you so that your handler could write a "next message will use encoder X" type message before sending the text.

        4) Use the DemuxingProtocolEncoder along with a LineFeedMessageEncoder and a PlainTextMessageEncoder but this would require that your handler used custom message types instead of just String objects.

        Show
        chase@osdev.org Matthieu Chase Heimer added a comment - I don't think modifying the TextLineEncoder or the TextLineCodecFactory is going to be the right approach. I did a quick glance at some of the code and there are some problems that you'd run into. First, there is only a single instance of the TextLineEncoder returned by the TextLineCodecFactory so even though the encoder is stored in the session you end up with all sessions storing a reference to the same encoder. So if you change the delimiter in one session's encoder you'd be changing it for all of them. You'd have to modify the encoder to read the current delimiter out of the session or modify the codecfactory to return different instances of the encoder per session to start with. Based on your discussion you need to send messages from the server to the client with and without a linefeed. The "without" part means you want to send text that is not a line. That would seem to be outside the scope of a TextLineEncoder. You have a couple of possible solutions. 1) Don't use the TextLineCodecFactory. It looks like TextLineDecoder is the right decoder for you but TextLineEncoder is the wrong one. Just create a basic text pass-through encoder and have your handler write your messages with/without linefeeds as needed. 2) The ProtocolCodecFilter looks like it will skip the encoding of the message being written if it is an instance of an IoBuffer. When you need to leave off the linefeed you could bypass the encoder by writing IoBuffer objects. 3) The ProtocolCodecFilter is pulling the encoder out of the IoSession. On a session by session basis you could swap the TextLineEncoder and a PassThoughEncoder in the session. You could even make a filter that handled the swapping for you so that your handler could write a "next message will use encoder X" type message before sending the text. 4) Use the DemuxingProtocolEncoder along with a LineFeedMessageEncoder and a PlainTextMessageEncoder but this would require that your handler used custom message types instead of just String objects.
        Hide
        vrm Julien Vermillard added a comment -

        moved to 3.0 due to feature freeze for 2.0

        Show
        vrm Julien Vermillard added a comment - moved to 3.0 due to feature freeze for 2.0
        Hide
        elecharny Emmanuel Lecharny added a comment -

        This is typically something one can handle though a dedicated protocol decoder. Modifying the TextLineDecoder to allow a dynamic configuration of the delimiter would make it more complex for the users who don't care about such a feature (ie, most of them).

        Show
        elecharny Emmanuel Lecharny added a comment - This is typically something one can handle though a dedicated protocol decoder. Modifying the TextLineDecoder to allow a dynamic configuration of the delimiter would make it more complex for the users who don't care about such a feature (ie, most of them).

          People

          • Assignee:
            Unassigned
            Reporter:
            trustin Trustin Lee
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development