Liveblog support

[rudygalfi]

I see a few paths to explore:

• Embedding through amp-iframe or (eventually) amp-click-to-play
• Potentially using amp-template with some modifications and/or wrapped in another component (that would handle the updating)
• New extended components built by liveblog platform providers

[jmadler]

In my mind, a Live Blog, as represented in AMP, would be a static AMP doc using the LiveBlogPosting markup, and an tag to pull new data.

After each new post, the document should be updated by the CMS to include the update in the body of the document, as well as the new BlogPosting data as children of the LiveBlogPosting structured data.

In order to maintain the freshness of the document following initial load, an tag, with a new "update" attribute, will continuously fetch new material for the document.

<amp-template data="https://example.com/liveblogs/2015/01-10-flight.json update="true">
    <div class="blogpost">
    {{#tweetid}}
            <amp-tweet id="{{tweetid}}"></amp-tweet>
    {{/tweetid}}
        {{#image}}
            <amp-img src="{{image}}" alt="{{text}"></amp-img>
    {{/image}}
        {{#video}}
            <amp-video src="{{video}" alt="{{text}}"></amp-video>
    {{/video}}
        {{text}}
    </div>
</amp-template>

One noted issue is that the Mustache.js syntax makes variable types unwieldy.

[nataliecarey]

Could this be a feature of https://github.com/ampproject/amphtml/tree/master/extensions/amp-mustache e.g. <amp-mustache update-interval=30></amp-mustache> or <amp-mustache auto-refresh delay=30></amp-mustache>.

Polling is easier to build and more annoying to use, pushing/websockets would be significantly more difficult to specify/build but should be significantly more pleasant to use. Long-polling support is a half-way point IMHO. Should we look to support auto-refresh behaviour as a precursor to a more useful solution? Some content providers would prefer to use auto-refresh so I can see it being a useful thing to support long-term. @dvoytenko - you seem to own that extension, do you have an opinion?

[dvoytenko]

@matcarey It won't be amp-mustache itself, but rather another extension. amp-mustache or any other type of template cannot render itself. But any other component can do rendering using templates. One such example is the amp-list component. Here, I imagine something like:

<amp-to-be-named update-interval=30>
  <template type="amp-mustache">
    <div class=blogpost>
      {{...}}
    </div>
  </template>
</amp-to-be-named>

As far as autorefresh concerned - my big preference would be for some sort of alert that new data is available and refresh itself done via user action. E.g. tap on the alert. But that's obviously TBD.

[nataliecarey]

This is something I'd like to take a look at, it's a feature the client I'm working with would like to use and has invested in on different platforms. I'd look to follow the shape that @dvoytenko has specified. The implementation looks like it's going to be relatively similar to https://github.com/ampproject/amphtml/tree/master/extensions/amp-list

I'd be perfectly happy to work with others or alone on this but I wouldn't want to duplicate/waste effort (mine or other people's) - is there anyone already working on implementing this feature? Is there anything that would put us off adding this feature?

Initial version would be only polling on an interval - it's the easiest to build, the least controversial, easiest to host & serve via CDN. I'd expect this to support long-polling AJAX and therefore the interval would be a delay between the end of rendering and the start of the next AJAX request and I wouldn't implement my own timeout.

Once we have that in place I'd like to discuss 'better' implementations, I imagine that things like websockets are going to lead to a better UX but be more controversial & harder to specify to everyone's needs.

[dvoytenko]

@matcarey No one works on this right at this moment. Let's discuss on Monday how we can go about it? I'm confident that we can start with some basic polling scenario and improve it. What are your thoughts on the protocol that AJAX call return?

Personally, I'm more concerned with user flow of this experience. E.g. avoiding page resizing and unexpected shuffles of UI, especially as the reader might be reading something else or scrolling. Obviously fixable with a good UX, but what are your thoughts on this?

[baynezy]

@dvoytenko what is your resistance to using an established push technology rather than polling? Sever-Sent Events, for example, would work with the syntax that @jmadler suggested and would allow near-instant updating.

[dvoytenko]

@baynezy I was intending to say that most of my concerns are after the update signal has been received. Long polling doesn't seem like a bad choice given that it's more or less universal and would likely be part of the final solution anyway. But what do you have in mind for an established push technology? We can go straight to websockets but then we will need to immediately come up with the fallback protocol. If we use an existing one, we'd need to see which one is the simplest to integrate on backends.

[mterenzio]

In addition to:

{{...}}

might not there also be something like:

Upon clicking would update the mustache template with the new data.

Values for action might be "append", "prepend", "replace"

On Tue, Dec 1, 2015 at 11:55 AM, Dima Voytenko notifications@github.com
wrote:

@baynezy https://github.com/baynezy I was intending to say that most of
my concerns are after the update signal has been received. Long polling
doesn't seem like a bad choice given that it's more or less universal and
would likely be part of the final solution anyway. But what do you have in
mind for an established push technology? We can go straight to websockets
but then we will need to immediately come up with the fallback protocol. If
we use an existing one, we'd need to see which one is the simplest to
integrate on backends.

—
Reply to this email directly or view it on GitHub
#909 (comment).

[dvoytenko]

@matcarey feel free to ping us at any time on slack if you'd like to discuss any details.

[nataliecarey]

Thanks, I've just signed up and started a chat.

[baynezy]

@dvoytenko I really like Server-Sent Events as it is standard HTTP and you can fall back to long polling using a polyfill if necessary. I prefer solutions that embrace standards.

[baynezy]

@dvoytenko as a follow up to this I wanted to clarify my stance.

Long polling a JSON end point feels like a fall-back for when something more useful is not supported. So I would rather that we followed an agreed standard for a supported real-time implementation. Then use long-polling as a fall-back/polyfill for older browsers.