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

[Jon Watte]

We looked at Thrift, back when it was Facebook's, and didn't like it
because:
1) It's more of an RPC framework than we wanted
2) It's significantly less compact (about 40% more overhead for our use
case)

If that's not a problem -- or if you're specifically looking for a
cross-platform RPC framework -- then Thrift can work very well!

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 Sat, Aug 27, 2011 at 2:57 AM, 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
>>
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110827/eb33bfb5/attachment.htm>