<div dir="ltr">Rich, are you willing to share your achievement in public?<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 19, 2014 at 9:57 PM, Rich Neswold <span dir="ltr"><<a href="mailto:rich.neswold@gmail.com" target="_blank">rich.neswold@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Sat, May 17, 2014 at 10:33 AM, Vlad Dumitrescu <<a href="mailto:vladdu55@gmail.com">vladdu55@gmail.com</a>> wrote:<br>

> I was thinking today (obvious from the number of mails to the list :-) ) and<br>
> was considering how great idea protocol checkers are and wondered why they<br>
> aren't used and popularized more.<br>
<br>
</div>Protocol checkers are wonderful.<br>
<div class=""><br>
> One of the possible reasons is that in order to be able to use them<br>
> everywhere, one has to use a specific architecture: with middleman processes<br>
> in front of every server process. This is somewhat clunky, introducing<br>
> elements that are not related to the application domain. Besides, it makes<br>
> it difficult to add them to existing applications.<br>
<br>
</div>A colleague and I have developed a protocol compiler which takes a<br>
protocol specification file and generates source code to<br>
marshal/unmarshal the messages. It's very similar to Google's protobuf<br>
idea and we seriously considered using their's, but there were some<br>
requirements at Fermilab which it didn't meet, so we rolled our own.<br>
We support C++, Java, Objective-C and Erlang (which are all used in<br>
our Control System) and we also target Python and OCaml (which are<br>
experimental.)<br>
<br>
We don't use middleware: each generator uses the target language's<br>
method of choice to prep an outgoing message. So, for example, the C++<br>
code will write to a stream; the Erlang code builds a binary (which<br>
can then be sent to a socket.); etc.<br>
<br>
The generated code for each target language validates the messages and<br>
will only succeed if every required field is present and is of the<br>
correct type and in range. Handling protocols, before this tool was<br>
created, was tedious and error-prone. Now adding features is a breeze<br>
and we regularly add or refactor protocol messages.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Rich<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>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Park, Sungjin<div>-------------------------------------------------------------------------------------------------------------------</div><div>Peculiar travel suggestions are dancing lessons from god.</div>
<div>  -- The Books of Bokonon</div><div>-------------------------------------------------------------------------------------------------------------------</div>
</div>