Server-side access implementation

[dvoytenko]

This implementation is completely symmetric to the client side. The new article-server.amp.html is the same as article-client.amp.html with the exception of META AMP-Access tag where it declares type=server.

The implementation is fairly complete vis-a-vis client side. The only two pieces missing are autologin and optimistic execution.

Pingback is currently missing in both client and server side and will be prototyped next.

Notes on review: changes to "cache/proxy.js", "cache/server.js", "cache/util.js" and "cache/accessdb.js" are just cruft. The most important changes are in "cache/ampproxy.js" and "cache/client/amp-access.js".

[cramforce]

You're such an evil maniac :)

Is there a chance of server skew between the 2 requests?

[dvoytenko]

Yes. Definitely a chance. I called it out somewhere above. We have couple of options: force publishers to specify IDs (and hope they do it right) or build more stable IDs ourselves, e.g. by using path information. Simple transient 1-inf number is definitely not a great idea.

[dvoytenko]

Yet another option: make cache more sticky. E.g. we ensure that we keep this document in cache for, e.g. 15 minutes, with the version#, even if new version is available. Then when server access request arrives, it will contain version# and as much as possible we will try to resolve it against that version.

[cramforce]

The right way to do this is to return the version of the doc on the first response and then do a "read at X" on the follow up.

But that really only makes sense if the SCS bigtable can do that efficiently.

[cramforce]

LGTM