[erlang-questions] BERT vs protobuf in the erlang world

[Jon Watte]

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.



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.


I really find it odd that protobuf doesn't provide a CHOICE construct.


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.
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.

Sincerely,

jw

--
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.




On Thu, Aug 25, 2011 at 3:04 AM, Vincent de Phily <
vincent.dephily@REDACTED> wrote:


> On Wednesday 24 August 2011 15:15:57 Jon Watte wrote:
> > You solve that in one of two ways:
> > 1) Create a message that is the "PDU" that contains the union of
> everything
> > that could be sent,
> > or
> > 2) Create a wrapper that is just "type" followed by "binary data that is
> a
> > marshaled message."
> >
> > If you believe that the entirety of a protocol should be described by
> that
> > protocol, then 1) is actually a fine solution. The preserve-and-forward
> > semantic of unknown field ids means that forward compatibility is still
> > possible.
> >
> > message MyProtocolPDU {
> >   optional SomeMessage some_message = 1;
> >   optional AnotherMessage other_message = 2;
> >   ...
> > }
> >
> > So, encoding a MyProtocolPDU that contains a SomeMessage will end up
> being
> > different than encoding a MyProtocolPDU that contains an AnotherMessage.
> > At the high level, you have to know that there is only one member in each
> > MyProtocolPDU; I find that to be quite acceptable.
>
>
> Yup, they're reasonable solutions (as long as you planed ahead). 2) may be
> ugly and innefficient, but it has been used as a pragmatic solution in
> countless formats. 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. I really find it odd that protobuf doesn't provide a
> CHOICE construct.
>
> --
> Vincent de Phily
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110826/4df91b67/attachment.htm>