[erlang-questions] fyi: Google protocol buffers
Wed Jul 9 21:30:03 CEST 2008
john s wolter wrote:
> 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:firstname.lastname@example.org/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
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.
More information about the erlang-questions