Open Stack

> 
> Russell did originally add a config option to allow enabling the new
> format, but I said:
> 
> Why would a user choose to enable the new format now? Isn't there
> basically no benefit until we start using the new format to do
> something interesting in H?
> 


Perhaps my concern come late, but I do have an outstanding question if the new envelope format is really a good thing, as presently designed.

Message signing requires that the signed message is a string including at least some bits being serialized. That message will need to include the actual message_data, but also the topic, a timestamp, ttl, etc. These are pieces that will need to become part of the envelope. They need to be either serialized along with the message data or concatenated with the message data to be signed.  Serializing these pieces together seems far more optimal.  However, keep in mind that the message signature chain will need to be separate.

Furthermore, the code currently double-serializes all the content. Kombu serializes data with JSON transparently, unless told otherwise, and the same is done with ZeroMQ.  At least with ZeroMQ, if the array is convertable via bytes(), then we can send it without the double serialization, but the envelope is currently a dict, so the double-serialization is still required... I'm not so certain if we can avoid it for Kombu, but I do know the default JSON serialization can be disabled.

Additionally, unless the envelope is an array that can be converted to bytes(), the ZeroMQ driver will continue to require a driver-specific envelope around the generic RPC envelope for purposes of performance.

Regards,
Eric Windisch