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

Peter Neumark <>
Sat Aug 27 11:57:33 CEST 2011


I'm surprised Apache Thrift wasn't mentioned yet in this thread.
Thrift is inspired by protobuf, so it sports s similar (although more
modular) design.
It supports a wide range a languages, several protocols and transports (with
the ability to add your own).
The erlang lib + code generator code is actively developed and already works
quite well.

Peter

On Sat, Aug 27, 2011 at 5:43 AM, Jon Watte <> wrote:

> 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 <
> > 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
>>
>>
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110827/32af5a59/attachment.html>


More information about the erlang-questions mailing list