[erlang-questions] fyi: Google protocol buffers

[Darren New]

john s wolter wrote:
> Darren,
> 
>     I see many protocols developed that are reinventions of "committee"
>     protocols that are "simpler" because they throw away a bunch of things
>     that only some people in the committee wanted.
> 
> 
> Still, somehow the Internet muddles ahead.

Indeed. (For that matter, this happens repeatedly in the internet, too. 
HTTP throws away a bunch of stuff FTP does, only to reinvent it later. 
OpenVPN throws away a bunch of stuff IPSec does, and will probably need 
to reinvent it, etc.)

I wasn't really making a value judgement.

>     Where ASN.1, Google's proto, and XML are all presentation-layer
>     specifications, BEEP is a session-layer specification.
> 
> I was thinking in a broad sense of getting my application working.  As 
> you mention the others are presentation-layers.

Yes. I was simply clarifying / expanding upon your statements for the 
benefit of anyone who might be interested (or not) based on a quick 
summary as to what it actually *is*. :-)

> I've read the statements but have yet to try a REST[ful]  application.  
> I can see some page mashups usage but have yet to see an web services 
> application that gets me interested.  The URI router also has overhead.

I've done a lot of work with the Amazon restful applications. CouchDB is 
the first application that actually looks like it's trying to be REST 
instead of just trying to be "not SOAP". :-)

> I see you are trying to contrast RESTful and REST.  Is there more you 
> might say to highlight the difference between the two terms from your 
> point of viewing this.

If your application doesn't work with caching, or your URIs don't point 
to data objects, or if those data objects don't have URIs/URLs referring 
to other data objects, or you store state at the server, or you have 
information in the body of the message saying the format you need 
instead of in the Accept-* headers, or your authentication isn't baed on 
the HTTP authentications, you're restful instead of REST.

For example, Amazon's S3 interface requires that every access have 
certain headers hashed in a certain order, with an extra header added to 
the request to present that hash. You can't just use HTTP's normal 
authentication mechanisms. There's no 
http://darren:mypassword@s3.amazonaws.com/mybucket/mydata URL to access 
my data. Instead, *if* you want to do this, you have to do calculations 
outside your HTTP library and tack stuff on the end of the URL with 
query arguments to authenticate, and then that (as far as I remember) 
only works with GET.

Once you get the result back from a bucket listing, there's nothing in 
the XML therein to tell you what is data you can fetch. Nothing looks 
like a URL. If I handed you the body of a search result without the 
documentation of what fields mean what, you wouldn't be able to find 
anything based on that.

When you set the permissions on an object, "all users" and "all users 
with an amazon account" are represented as URIs, but individual users 
are not. If you want to say "the user whose email address is 
me@REDACTED can read this", you don't include any mailto:. If you 
want to say "the user who Amazon knows as 1384719384", there's no scheme 
or anything else there either.

Those are examples of the differences. Compare with the stuff CouchDB 
supports, and you'll see the differences.

-- 
Darren New / San Diego, CA, USA (PST)
  Helpful housekeeping hints:
   Check your feather pillows for holes
    before putting them in the washing machine.