It is true that the erlang socket server which ships with thrift is synchronous (it's a gen_server).<div>This code is not generated, however. It is possible to create your own async server without touching the code generator.</div>
<div>I know because I am writing a server for use with socket.io-erlang (which is async).</div><div><br></div><div>Peter<br><br><div class="gmail_quote">On Sat, Aug 27, 2011 at 3:57 PM, Wenqiang Song <span dir="ltr"><<a href="mailto:wsong.cn@gmail.com">wsong.cn@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I second this. But the code generator directly generates synchronous<br>
socket server which is hard to embed into an existing asynchronous<br>
server.<br>
<br>
Andy<br>
<div><div></div><div class="h5"><br>
On 8/27/11, Peter Neumark <<a href="mailto:neumark.peter@gmail.com">neumark.peter@gmail.com</a>> wrote:<br>
> I'm surprised Apache Thrift wasn't mentioned yet in this thread.<br>
> Thrift is inspired by protobuf, so it sports s similar (although more<br>
> modular) design.<br>
> It supports a wide range a languages, several protocols and transports (with<br>
> the ability to add your own).<br>
> The erlang lib + code generator code is actively developed and already works<br>
> quite well.<br>
><br>
> Peter<br>
><br>
> On Sat, Aug 27, 2011 at 5:43 AM, Jon Watte <<a href="mailto:jwatte@gmail.com">jwatte@gmail.com</a>> wrote:<br>
><br>
>> 1) works as long as you control the sender or you have a well-defined<br>
>> policy when multiple fields are present, but I'd otherwise consider it a<br>
>> footgun.<br>
>><br>
>><br>
>><br>
>> Your policy could easily be "there is only one field present at the top<br>
>> level" -- the next field encountered would simply be considered its own<br>
>> PDU.<br>
>><br>
>><br>
>> I really find it odd that protobuf doesn't provide a CHOICE construct.<br>
>><br>
>><br>
>> The argument is that making everything optional gives you the most of<br>
>> that,<br>
>> with no additional overhead. What you want is the additional rule that<br>
>> there<br>
>> is only ONE of those optionals, something which can be added at the<br>
>> application layer if it's needed.<br>
>> I'm not saying it wouldn't be nice if "switch" and PDU naming/segmenting<br>
>> were supported in protobuf -- that would be sweet! But we deal pretty well<br>
>> without it, and still find it better than the alternatives, especially for<br>
>> cross-language projects.<br>
>><br>
>> Sincerely,<br>
>><br>
>> jw<br>
>><br>
>> --<br>
>> Americans might object: there is no way we would sacrifice our living<br>
>> standards for the benefit of people in the rest of the world.<br>
>> Nevertheless,<br>
>> whether we get there willingly or not, we shall soon have lower<br>
>> consumption<br>
>> rates, because our present rates are unsustainable.<br>
>><br>
>><br>
>><br>
>><br>
>> On Thu, Aug 25, 2011 at 3:04 AM, Vincent de Phily <<br>
>> <a href="mailto:vincent.dephily@mobile-devices.fr">vincent.dephily@mobile-devices.fr</a>> wrote:<br>
>><br>
>><br>
>>> On Wednesday 24 August 2011 15:15:57 Jon Watte wrote:<br>
>>> > You solve that in one of two ways:<br>
>>> > 1) Create a message that is the "PDU" that contains the union of<br>
>>> everything<br>
>>> > that could be sent,<br>
>>> > or<br>
>>> > 2) Create a wrapper that is just "type" followed by "binary data that<br>
>>> > is<br>
>>> a<br>
>>> > marshaled message."<br>
>>> ><br>
>>> > If you believe that the entirety of a protocol should be described by<br>
>>> that<br>
>>> > protocol, then 1) is actually a fine solution. The preserve-and-forward<br>
>>> > semantic of unknown field ids means that forward compatibility is still<br>
>>> > possible.<br>
>>> ><br>
>>> > message MyProtocolPDU {<br>
>>> >   optional SomeMessage some_message = 1;<br>
>>> >   optional AnotherMessage other_message = 2;<br>
>>> >   ...<br>
>>> > }<br>
>>> ><br>
>>> > So, encoding a MyProtocolPDU that contains a SomeMessage will end up<br>
>>> being<br>
>>> > different than encoding a MyProtocolPDU that contains an<br>
>>> > AnotherMessage.<br>
>>> > At the high level, you have to know that there is only one member in<br>
>>> each<br>
>>> > MyProtocolPDU; I find that to be quite acceptable.<br>
>>><br>
>>><br>
>>> Yup, they're reasonable solutions (as long as you planed ahead). 2) may<br>
>>> be<br>
>>> ugly and innefficient, but it has been used as a pragmatic solution in<br>
>>> countless formats. 1) works as long as you control the sender or you have<br>
>>> a<br>
>>> well-defined policy when multiple fields are present, but I'd otherwise<br>
>>> consider it a footgun. I really find it odd that protobuf doesn't provide<br>
>>> a<br>
>>> CHOICE construct.<br>
>>><br>
>>> --<br>
>>> Vincent de Phily<br>
>>><br>
>>><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> erlang-questions mailing list<br>
>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
>><br>
>><br>
><br>
<br>
</div></div><font color="#888888">--<br>
Sent from my mobile device<br>
<br>
---------------------------------------------------------------<br>
有志者，事竟成，破釜沉舟，百二秦关终属楚<br>
苦心人，天不负，卧薪尝胆，三千越甲可吞吴<br>
</font></blockquote></div><br></div>