Storage queue service should automatically encode/decode base 64

[huguesv]

The other SDKs (.NET, Node.js) do that, so if you want to interop with them, it's currently the user's responsibility to do the encoding/decoding when using the Python SDK.

We should make it transparent and automatically encode/decode base64 when sending/receiving queue messages.

This would be a breaking change.

If we don't do this, we should fix the docs at http://azure.microsoft.com/en-us/documentation/articles/storage-python-how-to-use-queue-storage to show the encoding/decoding code required on the client's side.

[cheif]

I totally agree, the main idea of a SDK is to abstract away the implementation-details of the underlying resource, such as the transport using base64.

I think the best way to break the API is to bundle the breaking changes into a new major release (that would be 1.0.0 in this case), I think that there are some other things that also could be have a better abstraction (e.g. that StorageQueue.get_messages() should be a generator an not take a num_messages argument, that is also a leaky abstraction) or could be more pythonic (e.g. that QueueMessage-objects should be able to delete themselves, without using a StorageQueue-object, and a Blob-object being able to read their own data)

EDIT:
I realize that the "more-pythonic" changes can be implemented without breaking the API, I'd be happy to create a PR if others also think it's a good idea?

[saschagottfried]

I had this issue this week with version 0.8.0 while developing code that receives queue messages transporting just a GUID that was inserted by .NET code. Since the .NET client did not insert XML or JSON into queue message I did not recognize the data as a base64 string. After checking .NET code is using usual code to insert queues messages, I eventually found MSDN information regarding base64 encoding/decoding of queue message.

I expected this topic to be in discussion, so I am happy that package developers themselves make that an issue.

base64 decoding was not a big deal. The real problem at least for me was that I, as a developer, was not aware of that need to decode. Help developer to be aware that there are conditions where message.message_text is a base64 encoded string and therefore has to be decoded. And yes, update your docs as a first step towards a more pythonic Message Queue API. Otherwise you may risk to reduce Python developer satisfaction. That's not what you want since Azure rocks.

@cheif
just do it and make a pull request. Open source is meant for contributions.

[crwilcox]

Issue Migrated to Azure/azure-storage-python#18