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

[Wenqiang Song]

I second this. But the code generator directly generates synchronous
socket server which is hard to embed into an existing asynchronous
server.

Andy

On 8/27/11, Peter Neumark <neumark.peter@REDACTED> wrote:
> 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 <jwatte@REDACTED> 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 <
>> 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
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>

-- 
Sent from my mobile device

---------------------------------------------------------------
有志者，事竟成，破釜沉舟，百二秦关终属楚
苦心人，天不负，卧薪尝胆，三千越甲可吞吴