Details

      Description

      This feature is for the completion of the QMFv2 implementation and language bindings (C++, Python, Ruby). This also includes cleanup and removal of stale code.

      In this deliverable:

      1) New QMFv2 implementation in C++ with ABI-stable interface in the same pattern as the stable messaging API.
      2) A Python binding to the API
      3) A Ruby binding to the API
      4) Support for QMFv2 formatted queries and methods in the broker agent (available in the C++ broker, not yet implemented in the Java broker)
      5) Documentation

        Activity

        Hide
        Ted Ross added a comment -

        There has been discussion about moving the QMF code out of the main source tree and into the "extras" tree. This is appropriate in that QMF is, as of v2, completely layered over messaging and does not require anything in the messaging broker beyond standard AMQP 0-10 behavior. I suggest raising a separate Jira for this effort because it will not be done in the Qpid 0.10 timeframe. Note that the pure Python implementation of QMF is already in the extras tree.

        The primary reason that the C++ implementation cannot yet be moved out of the main tree is that it uses non-public Qpid headers:

        1) It uses the qpid::sys namespace for locks, conditions, and other wrapped OS features.
        2) It uses the qpid::framing namespace (specifically Buffer and FieldTable) to construct and interpret QMFv1 messages for backward compatibility.

        Some possible approaches to consider:

        1) Move qpid::sys out of the main tree as it is also not messaging specific but more of a general-purpose OS abstraction layer.
        2) Provide a binary codec that puts AMQP-typed values into a buffer in-order without map or list overhead
        3) Fully deprecate QMFv1 (i.e. abandon backward compatibility)

        Show
        Ted Ross added a comment - There has been discussion about moving the QMF code out of the main source tree and into the "extras" tree. This is appropriate in that QMF is, as of v2, completely layered over messaging and does not require anything in the messaging broker beyond standard AMQP 0-10 behavior. I suggest raising a separate Jira for this effort because it will not be done in the Qpid 0.10 timeframe. Note that the pure Python implementation of QMF is already in the extras tree. The primary reason that the C++ implementation cannot yet be moved out of the main tree is that it uses non-public Qpid headers: 1) It uses the qpid::sys namespace for locks, conditions, and other wrapped OS features. 2) It uses the qpid::framing namespace (specifically Buffer and FieldTable) to construct and interpret QMFv1 messages for backward compatibility. Some possible approaches to consider: 1) Move qpid::sys out of the main tree as it is also not messaging specific but more of a general-purpose OS abstraction layer. 2) Provide a binary codec that puts AMQP-typed values into a buffer in-order without map or list overhead 3) Fully deprecate QMFv1 (i.e. abandon backward compatibility)
        Hide
        Ted Ross added a comment -

        Retargeting for 0.18. Per the discussion on the dev list, we plan to move the QMFv2 code out of the main broker/client tree into its own separate build.

        Show
        Ted Ross added a comment - Retargeting for 0.18. Per the discussion on the dev list, we plan to move the QMFv2 code out of the main broker/client tree into its own separate build.

          People

          • Assignee:
            Ted Ross
            Reporter:
            Ted Ross
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development