I'm more in favor of just having a schema, I don't care if that compiles to protocol buffers, json, NEWAWESOMEhipsterMSGFORMAT.
That schema will force people to think a little more when they add messages, and it will automatically document the messages that are being sent around. That's a big win I think and is a step to getting those schemas versioned... Just don't do pickling, pleaseeeeee (for other language users). On 4/24/12 8:39 AM, "Eric Windisch" <e...@cloudscaling.com> wrote: 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...) 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. 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. 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)
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
