[
https://issues.apache.org/jira/browse/PROTON-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Henry updated PROTON-33:
--------------------------------
Description:
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.
was:
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.
> 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
>
> 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
