[ https://issues.apache.org/jira/browse/PROTON-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafael H. Schloming updated PROTON-33: -------------------------------------- Issue Type: New Feature (was: Bug) > 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: New Feature > Components: proton-c > Reporter: William Henry > Labels: api > > 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 was sent by Atlassian JIRA (v6.1#6144)