Qpid Proton
  1. Qpid Proton
  2. PROTON-225

Redesign Transport interface such that Transport owns the in/out buffers rather than its client

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.3
    • Fix Version/s: 0.5
    • Component/s: None
    • Labels:
      None

      Description

      This issue is intended to cover the Transport API redesign proposed on the mailing list (http://qpid.2158936.n2.nabble.com/transport-interface-changes-td7588099.html) as part of discussions around PROTON-222. The redesign is being tracked under this new because we probably want to implement it on a different timescale to the PROTON-222 bug fix.

      When refactoring the Java implementation, we should consider if the point when the sent/received protocol logging is done should be changed. It should also address the difference around the use of PN_EOS (-1) that proton-c uses to signal that a) the engine will accept no further input and b) produce no further output.

        Issue Links

          Activity

          Philip Harvey created issue -
          Philip Harvey made changes -
          Field Original Value New Value
          Link This issue relates to PROTON-222 [ PROTON-222 ]
          Hide
          Ken Giusti added a comment -

          I'd recommend the following tweak to the proposed api:

          /** Push data from a transport's input buffer into the engine and

          • return how much data was succesfully pushed.
            *
          • @param[in] transport the transport
          • @param[size] the amount of data in the transport's input buffer
          • @return the amount of data consumed
            */
          • size_t pn_transport_push(pn_transport_t *transport, size_t size);
            + ssize_t pn_transport_push(pn_transport_t *transport, size_t size);

          From an implementation's point of view - the "push" will end up processing the new data. This could result in a failure, and the method's return value should be able to reflect that.

          Show
          Ken Giusti added a comment - I'd recommend the following tweak to the proposed api: /** Push data from a transport's input buffer into the engine and return how much data was succesfully pushed. * @param [in] transport the transport @param [size] the amount of data in the transport's input buffer @return the amount of data consumed */ size_t pn_transport_push(pn_transport_t *transport, size_t size); + ssize_t pn_transport_push(pn_transport_t *transport, size_t size); From an implementation's point of view - the "push" will end up processing the new data. This could result in a failure, and the method's return value should be able to reflect that.
          Ken Giusti made changes -
          Assignee Ken Giusti [ kgiusti ]
          Hide
          Ken Giusti added a comment -

          Reviewboard of proposed proton-c changes:

          https://reviews.apache.org/r/9434/

          Show
          Ken Giusti added a comment - Reviewboard of proposed proton-c changes: https://reviews.apache.org/r/9434/
          Ken Giusti made changes -
          Link This issue blocks PROTON-235 [ PROTON-235 ]
          Ken Giusti made changes -
          Link This issue blocks PROTON-241 [ PROTON-241 ]
          Show
          Ken Giusti added a comment - implemented for proton-c: http://svn.apache.org/viewvc?view=revision&revision=1446697 http://svn.apache.org/viewvc?view=revision&revision=1446744
          Philip Harvey made changes -
          Description This issue is intended to cover the Transport API redesign proposed on the mailing list (http://qpid.2158936.n2.nabble.com/transport-interface-changes-td7588099.html) as part of discussions around PROTON-222. The redesign is being tracked under this new because we probably want to implement it on a different timescale to the PROTON-222 bug fix. This issue is intended to cover the Transport API redesign proposed on the mailing list (http://qpid.2158936.n2.nabble.com/transport-interface-changes-td7588099.html) as part of discussions around PROTON-222. The redesign is being tracked under this new because we probably want to implement it on a different timescale to the PROTON-222 bug fix.

          When refactoring the Java implementation, we should consider if the point when the sent/received protocol logging is done should be changed.
          Keith Wall made changes -
          Description This issue is intended to cover the Transport API redesign proposed on the mailing list (http://qpid.2158936.n2.nabble.com/transport-interface-changes-td7588099.html) as part of discussions around PROTON-222. The redesign is being tracked under this new because we probably want to implement it on a different timescale to the PROTON-222 bug fix.

          When refactoring the Java implementation, we should consider if the point when the sent/received protocol logging is done should be changed.
          This issue is intended to cover the Transport API redesign proposed on the mailing list (http://qpid.2158936.n2.nabble.com/transport-interface-changes-td7588099.html) as part of discussions around PROTON-222. The redesign is being tracked under this new because we probably want to implement it on a different timescale to the PROTON-222 bug fix.

          When refactoring the Java implementation, we should consider if the point when the sent/received protocol logging is done should be changed. It should also address the difference around the use of PN_EOS (-1) that proton-c uses to signal that a) the engine will accept no further input and b) produce no further output.
          Keith Wall made changes -
          Link This issue is related to PROTON-264 [ PROTON-264 ]
          Hide
          Philip Harvey added a comment -

          proton-j changes committed in r1484842

          Show
          Philip Harvey added a comment - proton-j changes committed in r1484842
          Philip Harvey made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          Assignee Ken Giusti [ kgiusti ] Philip Harvey [ philharveyonline ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          102d 6h 45m 1 Philip Harvey 21/May/13 16:59

            People

            • Assignee:
              Philip Harvey
              Reporter:
              Philip Harvey
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development