[ https://issues.apache.org/jira/browse/PROTON-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafael H. Schloming updated PROTON-33: -------------------------------------- Fix Version/s: (was: 0.2) 0.4 > Provide API for user managed pn_message_t payload/memory > -------------------------------------------------------- > > Key: PROTON-33 > URL: https://issues.apache.org/jira/browse/PROTON-33 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c > Reporter: William Henry > Priority: Blocker > Labels: api > Fix For: 0.4 > > > Some users will have their own frameworks and methods of managing the data > received. > Currently in the pn_message_t the only way to get at the payload/data is to > call pn_message_save with a pre-allocated buffer of data. pn_message_save > copies to that data buffer and returns the actual size. (so for example if I > passed an allocated buffer of 1028 I might be returned 8 bytes). > In many situations this alloc is expensive - especially when integrating with > established frameworks that already do the copy - now there are two allocs. > I suggest an API call that returns the message payload as a pointer. There > is a risk that this might get deleted and a pn_message_t should check that > it's buffer is still valid (I assume it would.) In the case I'm looking at > the "other" framework is merely making it's own copy but doesn't free the > memory (but, as I said, there is a risk it could). > I'm willing to debate pn_message_t having an API that returns a copy but I > imagine many users will any up complaining about the alloc in the that API > call. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira