Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

amp-live-list.md polling clarification #5991

Merged
merged 1 commit into from
Nov 3, 2016
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion extensions/amp-live-list/amp-live-list.md
Original file line number Diff line number Diff line change
Expand Up @@ -79,7 +79,7 @@ In most implementations for live blogs, content is either pushed by the server
to the client instance of a page, or the client polls a JSON endpoint to receive
updates. The implementation for this component is different, in that the client
instance of the page polls the server copy of the document for updates to the
`items` reference point.
`items` reference point. For instance: if the user is viewing a document served from an AMP cache, the client will poll that document hosted on that AMP cache for updates; if the user is viewing a document served from a web publisher's origin domain (e.g. "example.com"), then the client will poll the document hosted on that origin domain for updates.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does that mean the document may often be one version behind the latest version pushed by the publisher, given how the AMP cache works?

Copy link
Contributor Author

@ericlindley-g ericlindley-g Nov 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the Google AMP Cache that's right — if the user is looking at a document served from that cache, each request (the initial page request, then each subsequent poll) will return content refreshed with the cache's one-behind (or stale-while-revalidate) model.

Web publishers can determine how fresh the content served is by:

a) using the Google AMP Cache's update ping when new content is published, in order to trigger the cache to fetch the newest version of the doc.

b) Tuning the polling frequency of the live blog to reduce the amount of time between the initial page load and the first poll

In practice, though, live blogs are typically made for breaking news, which may tend to get higher traffic (and inherently issue more page requests due to the polling mechanic), in turn triggering more page requests, and more frequent updates to caches using the one-behind model — effectively solving the issue itself.

This means that publishers of content do not need to set up a JSON endpoint or
push mechanism for this component to work. New content just needs to be
Expand Down