Torben & Christian,<br><br>The Google protocol is similar to ASN.1, see the Wikipedia ASN.1 links below which include an XML mapping link. I'm wondering as Google's documentation mentions, why the XML
version is so much slower in the Internet's already slow context. The
.proto approach can't be that much faster considering the time consumption of other processes in the chain of events. It could be a Google specific issue. Note however, this message handling kind of backend application is perfect for Erlang.<br>
<br>Here's Wikepedia's page on ASN.1...<br>
<a href="http://en.wikipedia.org/wiki/ASN.1">http://en.wikipedia.org/wiki/ASN.1</a><br>
<br>
Let me throw into the discussion some additional references and mention BEEP, Blocks Extensible Exchange Protocol. BEEP is more a well defined protocol helper.<br><br>Lastly just to expand this discussion, within web services API's there is this trend towards RESTful interface design to backend programs. Google is using RESTful like interfaces to many of its web services. The RESTful URI mapping is a natural application for Erlang.<br>
<br>My take on RESTful now is that it is a wrapper to object API's. Using Bertrand Meyer's words about objects, it is a wapper of runtime object features. A web server, on message arrival, passes a URI [object] to a router that maps the URI message to object's features. The claim is RESTful design is web URI consistent and thus better. I have not decided upon this yet.<br>
<br>I remembered BEEP from a few years ago as I was developing an online marketplace that needed secure and targeted protocol to the problem space. BEEP. BEEP covers what a network messaging protocol needs to cover. A kind of Meta requirements definition document gathered in one place.<br>
<br>BEEP's definition is here..<br><a href="http://tools.ietf.org/html/rfc3080">http://tools.ietf.org/html/rfc3080</a> , <br>
...and the TCP mapping here...<br><a href="http://tools.ietf.org/html/rfc3081">http://tools.ietf.org/html/rfc3081</a><br><br>Here's the BEEP web site...<br><a href="http://beepcore.org/">http://beepcore.org/</a><br><br>
An IBM DeveloperWorks article from 2001...<br><a href="http://www-128.ibm.com/developerworks/webservices/library/x-beep/">http://www-128.ibm.com/developerworks/webservices/library/x-beep/</a><br><br><div class="gmail_quote">
2008/7/9 Torben Hoffmann <<a href="mailto:torben.lehoff@googlemail.com">torben.lehoff@googlemail.com</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Nice, but I must be getting old, cynical or blind to the somehow obvious novelty in this. <br>Or maybe it is all of the above...<br><br>Anyway, I read through the documentation they have on this and it seems like it is a re-invention of ASN.1 when it comes to encoding and decoding of the messages you define the .proto files.<br>
<br>One can read more about ASN.1 @ <a href="http://asn1.elibel.tm.fr/tools/tutorial/" target="_blank">http://asn1.elibel.tm.fr/tools/tutorial/</a><br><br>I have only used 15 minutes to read about it, but I think I can spot an ASN.1 clone when I see one... ;-)<br>
<br>Or maybe a person brighter than me (there are bundles of these around) can explain why this approach is so much better than ASN.1?!?!<br><br>Cheers,<br>Torben<br><br>p.s. Any intentional or unintentional harshness in this mail is directed towards the creators of protocol buffers. Nothing but good wipes towards Christian.<br>
<br><div class="gmail_quote">On Tue, Jul 8, 2008 at 10:01 AM, Christian S <<a href="mailto:chsu79@gmail.com" target="_blank">chsu79@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<a href="http://code.google.com/apis/protocolbuffers/docs/overview.html" target="_blank">http://code.google.com/apis/protocolbuffers/docs/overview.html</a><br>
<br>
"Protocol buffers are now Google's lingua franca for data – at time of<br>
writing, there are 48,162 different message types defined in the<br>
Google code tree across 12,183 .proto files. They're used both in RPC<br>
systems and for persistent storage of data in a variety of storage<br>
systems."<br>
<br>
They're using it over XML, which I find noble (apparently XML has too<br>
much overhead even if you have thousands of machines, who would have<br>
known?), but protocol buffers it is no UBF. :-)<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote></div><br><br clear="all"><br>-- <br>John S. Wolter President<br>
Wolter Works<br>Mailto:<a href="mailto:johnswolter@wolterworks.com">johnswolter@wolterworks.com</a><br>Desk 1-734-665-1263<br>Cell: 1-734-904-8433