<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br><div><blockquote type="cite"><blockquote type="cite"><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px">It was decided that the request and response magic should be different.  I believe I added the definitions but didn't actually give them different values.<br> <br> </span></font></blockquote><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px">I have an email from you on 8/23 in which you said, “MAGIC BYTE 0xf  (for both requests and responses)”.  </span></font></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>I'm agreeing with you that it's wrong.  I just need to change one of the values.</div><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>I've published two servers and two clients since early July and nobody's called me on it yet.  I'd be pretty happy if that's the only mistake I've made.  :)</div><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px"> 2) We specified the command IDs a bit differently, grouping them by request/response type.<br> </span></font></blockquote><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px"><br> What is the value of this?  Is it not more valuable to just list them sequentially so implementors can easily tell what the commands are without computing them?<br> <br> </span></font></blockquote><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px">One possible use for this is that packet sniffers can decode messages even for unfamiliar commands.</span></font></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Well, only for some of them, at the cost of reducing the total number of available commands.  For example, incr as we discussed at the previous meeting doesn't fit any of your existing command models and would therefore not be any easier to decode.<br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>My proposal for making most commands at least somewhat decodeable to a packet sniffer by using the reserved byte as a key offset was shot down because it didn't provide enough value.<br class="webkit-block-placeholder"></div><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><font size="2"><font face="Courier New"><span style="font-size:10.0px"> #define BP_QUIET           BIT(3)<br> </span></font></font></blockquote><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px"><br> I suggested this in the first meeting and it was rejected.  The idea was to make commands (including quiet commands) with their specific semantics as needed.  For example, the desirable semantics of a quiet get are that there is no response body unless there's a success.  For a quiet set (if such a thing needs to exist), there should be no response body unless there's an error.<br> <br> </span></font></blockquote><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px">BP_QUIET is not a command.  It is a flag that is or’ed into the command to get the command ID of the quiet version of the same command.</span></font></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Yes, I read it.  I said I suggested the same thing at the first meeting and it was rejected.<br class="webkit-block-placeholder"></div><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">When does the server indicate an error status that's not in response to a command?</span></blockquote></blockquote><blockquote type="cite"><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px"> <br> </span></font></blockquote><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px">One possible instance is when the server cannot parse the requests.  It has no specific request to respond to in that situation.</span></font></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Why would you send a response when there is no request?  If you don't understand what the client is saying, it's probably best to just hang up on it.<br class="webkit-block-placeholder"></div><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">    // these commands go as a string_req and return as a string_rep.</span></blockquote><blockquote type="cite"><font size="2"><font face="Courier New"><span style="font-size:10.0px">      BP_STATS_CMD       = (BP_S_S | FIELD(0x0, 0)),<br> </span></font></font></blockquote><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px"><br> We discussed having more structure in the response to a stats command since there is structure in the stats result itself.  It makes sense to me to have the response be a list of sorts.<br> <br> </span></font></blockquote><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px">That is something I’ve considered as well, but for a first pass, I didn’t put too much thought into it.</span></font></blockquote><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>I've just ignored this part in the meantime.</div><div><br class="webkit-block-placeholder"></div><div> <span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>-- </div><div>Dustin Sallings</div><br class="Apple-interchange-newline"></span> </div><br></body></html>