Thanks for the pointer.  I found the etherpad:<div><div class="gmail_extra"><a href="http://etherpad.openstack.org/VersioningNovaRPCAPIs">http://etherpad.openstack.org/VersioningNovaRPCAPIs</a></div><div class="gmail_extra">
<br></div><div class="gmail_extra">Is there a blueprint that came / is coming out of that?<div></div><br>I think the data representation is orthogonal e.g. in theory, we could even use XML schemas:</div><div class="gmail_extra">
<font face="'courier new', monospace">PyDict --> XML --> XML Schema Validation --> Warn / Throw</font></div><div class="gmail_extra"><font face="'courier new', monospace">   \-----> JSON -> Rabbit</font></div>
<div class="gmail_extra"><br></div><div class="gmail_extra">As it sounds like we are using JSON, it makes most sense to use JSON schemas.  But doing so doesn't preclude us from using e.g. a binary format in future.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I'd imagine that the RPC mechanism would simply select the relevant schema based on a few attributes of the dict (likely the queue & method name).  So this would remain transparent to the caller.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">A basic RPC mechanisms might validate and warn against a JSON schema, another might use the schema to build a compact binary representation.  But I think we can achieve this without changing nova.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 24, 2012 at 8:39 AM, Eric Windisch <span dir="ltr"><<a href="mailto:eric@cloudscaling.com" target="_blank">eric@cloudscaling.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><span><div><div><div><div><div><br></div><div>Actually, I think JSON schema for our message-bus messages might be a really good idea (tm).  Violations could just be warnings until we get things locked down... maybe I should propose a blueprint? (Although I have enough of a blueprint backlog as it is...)</div>
</div></div></div></div></span></blockquote><div><br></div></div><div><span style="font-size:12px">This was discussed at the summit in (I believe) the API versioning talk. There is a strong bias toward JSON inside RPC messages. However, this is actually transparent to Nova as the RPC implementations do the decoding and encoding. It is also hard to test and trigger such warnings as, as far as Nova knows, all the interfaces pass python data types, not JSON.  Some RPC mechanisms could transparently serialize.  As long as there is an abstraction layer, it should be oblivious to the serialization and we should not care too strongly.</span></div>
<div><span style="font-size:12px"><br></span></div><div><span style="font-size:12px">There was a patch a few weeks ago that has enforced using a common RPC exception serializer using JSON, which I'm not sure is, or is not, a good thing. I haven't yet updated the ZeroMQ driver to use this, but am in the process of making these changes as I update for Folsom.</span></div>
<div><span style="font-size:12px"><br></span></div><div><span style="font-size:12px">All that said, I do intend that the ZeroMQ driver will use JSON when it lands in Folsom.   (it currently Pickles, but only because there was a bug in Essex at one point, breaking  JSON serialization)</span></div>
<span class="HOEnZb"><font color="#888888"><div><br></div>-- <br>Eric Windisch<div> </div><div><br>
                </div>
            </font></span></blockquote></div><br></div></div>