[erlang-questions] fyi: Google protocol buffers

[john s wolter]

Torben & Christian,

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.

Here's Wikepedia's page on ASN.1...
http://en.wikipedia.org/wiki/ASN.1

Let me throw into the discussion some additional references and mention
BEEP, Blocks Extensible Exchange Protocol.  BEEP is more a well defined
protocol helper.

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.

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.

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.

BEEP's definition is here..
http://tools.ietf.org/html/rfc3080 ,
...and the TCP mapping here...
http://tools.ietf.org/html/rfc3081

Here's the BEEP web site...
http://beepcore.org/

An IBM DeveloperWorks article from 2001...
http://www-128.ibm.com/developerworks/webservices/library/x-beep/

2008/7/9 Torben Hoffmann <torben.lehoff@REDACTED>:

> Nice, but I must be getting old, cynical or blind to the somehow obvious
> novelty in this.
> Or maybe it is all of the above...
>
> 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.
>
> One can read more about ASN.1 @ http://asn1.elibel.tm.fr/tools/tutorial/
>
> I have only used 15 minutes to read about it, but I think I can spot an
> ASN.1 clone when I see one... ;-)
>
> 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?!?!
>
> Cheers,
> Torben
>
> p.s. Any intentional or unintentional harshness in this mail is directed
> towards the creators of protocol buffers. Nothing but good wipes towards
> Christian.
>
> On Tue, Jul 8, 2008 at 10:01 AM, Christian S <chsu79@REDACTED> wrote:
>
>> http://code.google.com/apis/protocolbuffers/docs/overview.html
>>
>> "Protocol buffers are now Google's lingua franca for data – at time of
>> writing, there are 48,162 different message types defined in the
>> Google code tree across 12,183 .proto files. They're used both in RPC
>> systems and for persistent storage of data in a variety of storage
>> systems."
>>
>> They're using it over XML, which I find noble (apparently XML has too
>> much overhead even if you have thousands of machines, who would have
>> known?), but protocol buffers it is no UBF.  :-)
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



-- 
John S. Wolter President
Wolter Works
Mailto:johnswolter@REDACTED
Desk 1-734-665-1263
Cell: 1-734-904-8433
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080709/acba7250/attachment.htm>