<br><div><span class="gmail_quote">On 23/08/07, <b class="gmail_sendername">Matthias Radestock</b> <<a href="mailto:matthias@lshift.net">matthias@lshift.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Robert Godfrey wrote:<br>> My feeling is that any broker that supports 0-9 (non-WIP) should be able<br>> to also trivially support 0-8.<br><br>It's not that easy, unfortunately. 0-9 makes some changes to existing
<br>methods. For example, channel.open-ok gets an additional channel-id<br>field, and basic.consume gets an additional filter field. If, like us,<br>you are auto-generating the codec from the spec then this poses a problem.
</blockquote><div><br><br>Qpid auto generates code from the spec, but with changes this small I would think we could work in a few bits of non-generated code to support both versions. Given the degree of change in 0-10 I'm not wanting to expend much effort on 0-9 - but I think that having 0-9 compatability at the broker really shouldn't be a big deal (it may not be able to be done with particular beauty though). [For instance I think Qpid actually already has the
basic.consume filter argument].<br><br>Given Martin's claim that it took them 1 day to implement the changes... i would think that it should be possible for Qpid (and Rabbit if you like) to have versions that work with both protocol revisions. However the real focus will be on getting 0-10 implemented.
<br>
<br><br>-- Rob<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Matthias.<br></blockquote></div><br>