<div><blockquote style="margin-right: 0px;" dir="ltr"><p style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">1) works as long as you control the sender or you have a well-defined policy when multiple fields are present, but I'd otherwise consider it a footgun.</p>
</blockquote><p clear="all"> </p><div> </div><div>Your policy could easily be "there is only one field present at the top level" -- the next field encountered would simply be considered its own PDU.</div><div> </div>
</div><blockquote style="margin-right: 0px;" dir="ltr"><div>I really find it odd that protobuf doesn't provide a CHOICE construct.</div></blockquote><div> </div><div>The argument is that making everything optional gives you the most of that, with no additional overhead. What you want is the additional rule that there is only ONE of those optionals, something which can be added at the application layer if it's needed.</div>
<div>I'm not saying it wouldn't be nice if "switch" and PDU naming/segmenting were supported in protobuf -- that would be sweet! But we deal pretty well without it, and still find it better than the alternatives, especially for cross-language projects.</div>
<div> </div><div>Sincerely,</div><div> </div><div>jw</div><div> </div><div><div>--</div><div>Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. </div>
<div> </div><div>
 </div><div> </div><div> </div></div><div class="gmail_quote">On Thu, Aug 25, 2011 at 3:04 AM, Vincent de Phily <span dir="ltr"><<a href="mailto:vincent.dephily@mobile-devices.fr">vincent.dephily@mobile-devices.fr</a>></span> wrote:<div>
 </div><blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote"><div class="im">On Wednesday 24 August 2011 15:15:57 Jon Watte wrote:<div>

> You solve that in one of two ways:</div><div>
> 1) Create a message that is the "PDU" that contains the union of everything</div><div>
> that could be sent,</div><div>
> or</div><div>
> 2) Create a wrapper that is just "type" followed by "binary data that is a</div><div>
> marshaled message."</div><div>
></div><div>
> If you believe that the entirety of a protocol should be described by that</div><div>
> protocol, then 1) is actually a fine solution. The preserve-and-forward</div><div>
> semantic of unknown field ids means that forward compatibility is still</div><div>
> possible.</div><div>
></div><div>
> message MyProtocolPDU {</div><div>
>   optional SomeMessage some_message = 1;</div><div>
>   optional AnotherMessage other_message = 2;</div><div>
>   ...</div><div>
> }</div><div>
></div><div>
> So, encoding a MyProtocolPDU that contains a SomeMessage will end up being</div><div>
> different than encoding a MyProtocolPDU that contains an AnotherMessage.</div><div>
> At the high level, you have to know that there is only one member in each</div><div>
> MyProtocolPDU; I find that to be quite acceptable.</div><div>
 </div><div>
 </div></div>Yup, they're reasonable solutions (as long as you planed ahead). 2) may be<div>
ugly and innefficient, but it has been used as a pragmatic solution in</div><div>
countless formats. 1) works as long as you control the sender or you have a</div><div>
well-defined policy when multiple fields are present, but I'd otherwise</div><div>
consider it a footgun. I really find it odd that protobuf doesn't provide a</div><div>
CHOICE construct.</div><div>
 </div><div>
--</div><div>
<font color="#888888">Vincent de Phily</font></div><font color="#888888"><div>
 </div></font><div> </div></blockquote></div><div> </div>