Add four missing data management functions

[rhc54]

While we provided macros for these purposes, it turns out that the logic in implementing those macros is somewhat more complex that originally realized and better suited to an actual function call. We also missed functions for compressing/decompressing data. This RFC adds to functions in the Data Management chapter:

• PMIx_Data_load transfers a data "blob" from a pmix_byte_object_t structure to a pmix_data_buffer_t

• PMIx_Data_unload transfers the payload in a pmix_data_buffer_t to a pmix_byte_object_t structure

• PMIx_Data_compress applies a lossless data compression algo to the input data

• PMIx_Data_decompress decompresses the input data (which must have been compressed by PMIx_Data_compress)

Signed-off-by: Ralph Castain rhc@pmix.org

[rhc54]

Please use emoji reactions ON THIS COMMENT to indicate your position on this proposal.

• You do not need to vote on every proposal
• If you have no opinion, don't vote - that is also useful data
• If you've already commented on this issue, please still vote so
  we know your current thoughts
• Not all proposals solve exactly the same problem, so we may end
  up accepting proposals that appear to have some overlap
  This is not a binding majority-rule vote, but it will be a very
  significant input into the corresponding ASC decision.

Here are the meanings for the emojis:

• Hooray or Rocket: I support this so strongly that I
  want to be an advocate for it
• Heart: I think this is an ideal solution
• Thumbs up: I'd be happy with this solution
• Confused: I'd rather we not do this, but I can tolerate it
• Thumbs down: I'd be actively unhappy, and may even consider
  other technologies instead
  If you want to explain in more detail, feel free to add another
  comment, but please also vote on this comment.

[jjhursey]

Minor wording suggestions

[SteVwonder]

One question from the quarterly was whether or not these functions should also be exported through the python bindings. @jjhursey was wondering if any of the other pmix_data_* functions were in the python bindings. I don't think either of those were wrapped up on the call.

[jjhursey]

This PR adds some new functions. This PR is on the provisional track.

[jjhursey]

Implementation pointers

• Add: PMIx_Data_load
  • Implemented in Shift the process/node stat support to PMIx openpmix/openpmix#2039
• Add: PMIx_Data_unload
  • Implemented in Shift the process/node stat support to PMIx openpmix/openpmix#2039
• Add: PMIx_Data_compress
  • Implemented in Add compress/decompress APIs openpmix/openpmix#2068 and Fix signature of new compression APIs openpmix/openpmix#2070
• Add: PMIx_Data_decompress
  • Implemented in Add compress/decompress APIs openpmix/openpmix#2068 and Fix signature of new compression APIs openpmix/openpmix#2070

[raffenet]

Should the source buffer arguments in these APIs include a const qualifier?

[raffenet]

Should the source buffer arguments in these APIs include a const qualifier?

On closer reading, perhaps load and unload are correct in not using const? Compress and decompress look like good candidates for const, though.

[raffenet]

I would also advocate for consistent source and destination argument ordering for the compress/decompress APIs. For instance, zlib and libbz2 both use (dest, src) in the compress/uncompress APIs ala memcpy. Alternatively, l4z uses (src, dest) ordering. Whatever we land on, I think consistency would be good.

[jjhursey]

Notes from 2Q 2021 ASC Meeting:

• const should be added in this PR as needed since other Data Packing functions also have const specifier. (Revision exception vote)
• Argument ordering consistency discussion
  • Old: PMIx_Data_load(pmix_data_buffer_t *dest, pmix_byte_object_t *src); and PMIx_Data_unload(pmix_data_buffer_t *src, pmix_byte_object_t *dest);
  • New: PMIx_Data_load(pmix_byte_object_t *src, pmix_data_buffer_t *dest); and PMIx_Data_unload(pmix_data_buffer_t *src, pmix_byte_object_t *dest);
  • This would make it consistent with other compression APIs.
  • OpenPMIx v4.1 has this change as does PRRTE v2.0 - neither has been released yet.
  • Discussion favored fixing the signatures - Ken will make the suggested change. (Revision exception vote)

The base branch was changed.

[kathrynmohror]

@rhc54 This PR was accepted as provisional on the condition that you apply the change in the comment from @bwbarrett that contains the text 'revision exception' (adding const). Please let us know if you have any questions on this.

[rhc54]

@kathrynmohror I'm assuming you have a typo in your directions, and that you meant the comments from @raffenet and not @bwbarrett - yes?

[jjhursey]

PMIx ASC 2Q 2021: May 11 & May 13

• Passed first vote with Revision Exception: 7 yes / 0 no / 1 abstain
  • Failed without the Revision Exception): 0 yes / 6 no / 2 abstain
• I confirmed that the Revision Exception has been applied.
  • Implementation requirement completed in this commit in OpenPMIx
• This has been accepted as provisional.
• I will do the following today:
  • Update the branch
  • Merge it into v4
  • Cherry-pick to master

[jjhursey]

• Update the branch to v4 HEAD
• Merge it into v4
• No other text changes made