On Fri, Feb 15, 2013 at 03:50:28PM +0000, Gordon Sim wrote: > On 02/15/2013 03:29 PM, Steven Hardy wrote: > >Well, no - this is only addressing half of the problem - on the receiver > >side the binary buffer gets returned to the user as a string, but it's not > >converted back to the original format - so the message is corrupted and we > >have no way of knowing that conversion from binary is required. > > You could check the size and decode anything over 2^16... but I > agree that is not ideal. I'll consult some more on that(!)...
Well it seems like you can't use a size comparison, e.g in the reproducer example the _context_aws_creds key is 69529 bytes before the conversion to buffer(), and 278116 bytes afterwards. > >See my attached revised reproducer - maybe I'm missing something, but I > >don't see how we can detect the _context_aws_creds key has been binary > >encoded on the receiver side. > > > >It seems to me that the problem here is python-qpid encoding individual > >dict/map keys - wouldn't it be better to just dump the whole dict to a > >string (ie json), > > You can certainly do that. Just set the content to the original json > string and send it. To clarify, I was suggesting that the qpid codec write|read_map functions should do this, I don't think the user should have to worry about this type conversion themselves Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
