Unfortunately, I've just started writing the portion of the code which are would be interested in.<div>I will push it to github as soon as it works. In the meantime you can check out what I have here:</div><div><a href="https://github.com/postlock/thrift-over-socketio">https://github.com/postlock/thrift-over-socketio</a></div>
<div><br></div><div>Peter<br><br><div class="gmail_quote">On Sun, Aug 28, 2011 at 1:18 AM, 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;">
You are right, the socket server is in lib/erl. The whole Erlang<br>
library is tightly bound to synchronous model and hard to modify. Do<br>
you mind sharing your code?<br>
<br>
Thanks<br>
Andy<br>
<div><div></div><div class="h5"><br>
On 8/28/11, Peter Neumark <<a href="mailto:neumark.peter@gmail.com">neumark.peter@gmail.com</a>> wrote:<br>
> It is true that the erlang socket server which ships with thrift is<br>
> synchronous (it's a gen_server).<br>
> This code is not generated, however. It is possible to create your own async<br>
> server without touching the code generator.<br>
> I know because I am writing a server for use with socket.io-erlang (which is<br>
> async).<br>
><br>
> Peter<br>
><br>
> On Sat, Aug 27, 2011 at 3:57 PM, Wenqiang Song <<a href="mailto:wsong.cn@gmail.com">wsong.cn@gmail.com</a>> wrote:<br>
><br>
>> 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>
>><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<br>
>> (with<br>
>> > the ability to add your own).<br>
>> > The erlang lib + code generator code is actively developed and already<br>
>> 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<br>
>> >> 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<br>
>> >> naming/segmenting<br>
>> >> were supported in protobuf -- that would be sweet! But we deal pretty<br>
>> well<br>
>> >> without it, and still find it better than the alternatives, especially<br>
>> 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<br>
>> >>> > that<br>
>> >>> > is<br>
>> >>> a<br>
>> >>> > marshaled message."<br>
>> >>> ><br>
>> >>> > If you believe that the entirety of a protocol should be described<br>
>> >>> > by<br>
>> >>> that<br>
>> >>> > protocol, then 1) is actually a fine solution. The<br>
>> preserve-and-forward<br>
>> >>> > semantic of unknown field ids means that forward compatibility is<br>
>> 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)<br>
>> >>> 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<br>
>> have<br>
>> >>> a<br>
>> >>> well-defined policy when multiple fields are present, but I'd<br>
>> >>> otherwise<br>
>> >>> consider it a footgun. I really find it odd that protobuf doesn't<br>
>> 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>
>> --<br>
>> Sent from my mobile device<br>
>><br>
>> ---------------------------------------------------------------<br>
>> 有志者，事竟成，破釜沉舟，百二秦关终属楚<br>
>> 苦心人，天不负，卧薪尝胆，三千越甲可吞吴<br>
>><br>
><br>
<br>
</div></div>--<br>
<div><div></div><div class="h5">Sent from my mobile device<br>
<br>
---------------------------------------------------------------<br>
有志者，事竟成，破釜沉舟，百二秦关终属楚<br>
苦心人，天不负，卧薪尝胆，三千越甲可吞吴<br>
</div></div></blockquote></div><br></div>