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

[Peter Neumark]

It is true that the erlang socket server which ships with thrift is
synchronous (it's a gen_server).
This code is not generated, however. It is possible to create your own async
server without touching the code generator.
I know because I am writing a server for use with socket.io-erlang (which is
async).

Peter

On Sat, Aug 27, 2011 at 3:57 PM, Wenqiang Song <wsong.cn@REDACTED> wrote:

> 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
>
> ---------------------------------------------------------------
> 有志者，事竟成，破釜沉舟，百二秦关终属楚
> 苦心人，天不负，卧薪尝胆，三千越甲可吞吴
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110827/a97796e2/attachment.htm>