Qpid Proton
  1. Qpid Proton
  2. PROTON-191

Proton-API reconciliation reporting tool

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.4
    • Component/s: proton-c, proton-j
    • Labels:
      None

      Description

      Add standalone tool that reconciles the public functions of the Proton-C API against the public API of the Proton-J API. Used so we can easily spot gaps in one implementation or the other.

        Activity

        Hide
        Keith Wall added a comment -

        Patch applied to jni-binding branch only.

        Show
        Keith Wall added a comment - Patch applied to jni-binding branch only.
        Hide
        Philip Harvey added a comment -

        After doing an initial sweep, and discussing with Rob Godfrey, the following discrepancies have been identified, many of which will be addressed in separate Jiras.

        1. The pn_condition_* functions all correspond to the functionality within ErronCondition et al. We need to manually check whether they are logically equivalent.
        2. The codec-related pn_data_* functions (plus pn_message_data) will soon have Proton-J equivalents. Rob Godfrey is working on this.
        3. Numerous Driver-related proton-c functions have no proton-j equivalent yet. Gordon Sim is working on the proton-j Driver so we should revisit after that work is committed. In many cases, there is probably little point wrapping a proton-c driver in a Java wrapper.
        4. The pn_error_* functions have no proton-j equivalents. We need to revisit error handling, error codes etc before addressing this.
        5. We don't yet know what pn_message_inferred does, so not sure if it needs a proton-j equivalent
        6. We need to consider how to do the equivalent of pn_free_* in proton-j across the board. This isn't just a mechanical function mapping because of the different memory management approaches of Java and C.
        7. Java and C programs have quite different norms for setting up SSL (roughly speaking, setTrustStore/KeyStore and setPemFile respectively), so we need to think whether there should be an equivalent method for functions such as pn_messenger_set_trusted_certificates etc.
        8. We don't think pn_parser_* or pn_scanner_* need a proton-j equivalent.
        9. pn_ssl_get_peer_hostname and pn_ssl_set_peer_hostname relate to PROTON-161 which has not yet been implemented in proton-j.
        10. pn_terminus_capabilities is called by Link.setSource/Target. However, we need to modify how subsequent mutation of sources and targets is done, possibly by doing a deep copy before serialising them. Similar issues apply to Message.setAnnotations.
        11. We need have a general logging discussion before we can add a proton-j equivalent for pn_transport_trace.
        Show
        Philip Harvey added a comment - After doing an initial sweep, and discussing with Rob Godfrey, the following discrepancies have been identified, many of which will be addressed in separate Jiras. The pn_condition_* functions all correspond to the functionality within ErronCondition et al. We need to manually check whether they are logically equivalent. The codec-related pn_data_* functions (plus pn_message_data) will soon have Proton-J equivalents. Rob Godfrey is working on this. Numerous Driver-related proton-c functions have no proton-j equivalent yet. Gordon Sim is working on the proton-j Driver so we should revisit after that work is committed. In many cases, there is probably little point wrapping a proton-c driver in a Java wrapper. The pn_error_* functions have no proton-j equivalents. We need to revisit error handling, error codes etc before addressing this. We don't yet know what pn_message_inferred does, so not sure if it needs a proton-j equivalent We need to consider how to do the equivalent of pn_free_* in proton-j across the board. This isn't just a mechanical function mapping because of the different memory management approaches of Java and C. Java and C programs have quite different norms for setting up SSL (roughly speaking, setTrustStore/KeyStore and setPemFile respectively), so we need to think whether there should be an equivalent method for functions such as pn_messenger_set_trusted_certificates etc. We don't think pn_parser_* or pn_scanner_* need a proton-j equivalent. pn_ssl_get_peer_hostname and pn_ssl_set_peer_hostname relate to PROTON-161 which has not yet been implemented in proton-j. pn_terminus_capabilities is called by Link.setSource/Target. However, we need to modify how subsequent mutation of sources and targets is done, possibly by doing a deep copy before serialising them. Similar issues apply to Message.setAnnotations. We need have a general logging discussion before we can add a proton-j equivalent for pn_transport_trace.
        Hide
        Keith Wall added a comment -

        Patch applied to jni-branch.

        Show
        Keith Wall added a comment - Patch applied to jni-branch.

          People

          • Assignee:
            Keith Wall
            Reporter:
            Keith Wall
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development