Comment Re:Why? It's and open standard ... (Score 1) 190
You seem really, really confused about the technical details. [AMP] isn't a cache. [...] A cache returns the thing cached [and a] proxy alters the data for each user [and] is not a cache at all.
It's always such a treasure to find someone who pokes fun at another user's technical knowledge only to absolutely fail at their own attempt at an explanation. Slashdot really is a mythical place, where users feel entitled to talk down to their fellow readers regarding topics they have absolutely no fundamental knowledge of.
First lets look deeper into your understanding of the most basic of terms: "cache" and "proxy". You do realize that a "cache" and a "proxy" aren't mutually exclusive, right? There are, in fact, proxy servers that also perform caching responsibilities (making such implementations both a "cache" and a "proxy"). It is entirely common for software to act in both compacities, or for two or more discrete services to work in tandem to provide said set of features. As it doesn't appear you have any first-hand experience working with this types of software, you may want to reference Wikipedia's articles on caches and proxies before taking another stab at commenting about AMP or any similar technologies.
Regarding AMP specifically, your statements are again incorrect. Don't take my word for it though, you can check all of the following resources to verify my assertions, if you feel so inclined: [1], [2], [3], [4], and [5]. To save you some time, here is a brief writeup from the developer documentation regarding the caching mechanics of AMP:
When a user requests an AMP document from the Google AMP Cache, the cache automatically requests updates in order to be able to serve fresh content for the next user once the content has been cached. With this model, updates to AMP documents propagate automatically and quickly; few users will see the non-updated version after your update. The cache follows a "stale-while-revalidate" model. It uses the origin's caching headers, such as Max-Age, as hints in deciding whether a particular document or resource is stale. When a user makes a request for something that is stale, that request causes a new copy to be fetched, so that the next user gets fresh content. To limit the amount of load it generates for publisher sites, the Google AMP Cache considers any document fresh for at least 15 seconds, and any resource fresh for at least 1 minute. Note that those numbers may change in the future, as we tune the cache for optimum balance between freshness and load on publisher sites.
-https://developers.google.com/amp/cache/overview#google-amp-cache-updates
It is important to note that AMP doesn't require use of Google's cache component. Those looking to implement the AMP specification have a broad array of choices regarding behavior of their content.