GET http://blah.com/entries?fields=entry(title,gd:rating,@gd:*)
GET http://blah.com/entries?fields=entry(title)

The second returns a sub-set of the first response, but both will end up as different cache objects. It’s not a big deal if both requests are coming from beside the US datacentre where the responses originate, however Australia to the US is a big deal. I would prefer to hit a cache in Australia and get slightly more data than I need vs going all the way back to the origin server just to shave a few bytes. The difference in latency can be enormous, particularly at global scale. Not to mention the extra load that this incurs on the origin servers.

Anyways, I don’t think Richardson has anything to say about this specifically. I would imagine that a more appropriate approach to partial responses would be to break up into sub-resources and allow for sub-resources to be combined into bigger responses, not the other way around (and of course providing hyperlinks to combine sub-resources). This allows the server-side to constrain the total number of representations that can be fetched while in the Google case there can be hundreds of representations of the same data, just depending on the order of the query parameters (since most HTTP caches cache based on a simple hash of the URL).

But, I still have no great solution for mobile clients We’ll decide something soon I hope.

As for too many requests, or how to cache all this around the world – no one said it would be easy.

There is a .net version of this library too.

The library provides for automatic reconnect and retransmission. Currently it only deals with one particular message pattern – point-to-point – but it should be possible to extend this to other use cases.

When we talk of strings in Erlang, we usually mean the list of characters as Alvero eludes to, and indeed the literal “Hello World” will be compiled to a list.

However, from a storage point-of-view, the binary representation probably has more in common with the string types you are familiar with. The literal <> compiles to a binary.

Atoms are properly used as constant values, much like the “#DEFINE” in C or the “static final String” in Java. Atom literals need not be quoted if they start with a lowercase letter and contain only alphanumerics or _ or @. Otherwise they are quoted using single quotes like ‘Hello World’.