<div>At present, at least for some message types, the AMQP drivers are modifying message contents by adding key/values to the dict passed by the developer. With the RPC envelope, it will become possible to begin treating these dict as immutable types. For instance, the ZeroMQ driver which already wraps the message dict in its own envelope, treats the original message as immutable.</div><div><br></div><div>At present, I've been talking with Ray Pekowski about passing additional metadata along with messages. For instance, adding a unique nonce or identifier for purposes of replay detection. We have been debating if this should belong in the envelope, treating the original message dict as immutable, or if we should feel comfortable modifying the message contents in the long-term.  I believe we both agree that we need to modify the message contents in the short-term for Folsom compatibility.</div><div><br></div><div>Ray and I discussed SMTP headers and how they are modified by the implementations. However, when messages are multi-part, the non-header parts are left unmodified. I feel that with envelopes providing an analogue to multi-part messaging, we can look to begin a process of treating messages as immutable.</div><div><br></div><div>The other argument is that as long as the message is structured, we just treat some fields of the user-supplied message as immutable. However, I'm not certain that we can expect that messages are structured in the case of, say, notifications. I believe that other than the RPC envelope itself, these are often passed simply as strings, yes? We certainly can't add new key/vals to that.</div><div><br></div><div>I also feel that we lose some of the value of envelope versioning if we simply manipulate the content of the data being passed (besides wrapping around it).</div><div><br></div><div>I'd appreciate feedback from the other developers involved with RPC messaging as well as those generating and consuming notifications.</div>
                <div><div><br></div><div>Regards,</div><div>Eric Windisch</div><div><br></div></div>