Re: Can a publication change over time?

WP's would themselves be offline-first "web apps." At least we highlighted in the DPIG that they are available offline--as a requirement.


Consequently, ServiceWorkers (picking up where AppCache left off) provide the current method of making that happen. However, I've no intention of encouraging (and certainly not requiring) any WP author to write JS...unless they want to.

My expectation is more that authors will providing a "binding document" that the browser/reader uses to offline the application. In my head, that "binding document" is the Table of Contents of the publication. It provides the most knowledge of the shape of the work, can be authored by the author, and used by the browser/reader to create an offline-first copy of the publication (i.e. the copy the reader "holds").

It's an idea I want to explore further, but it feels like its on the right track. At least in my tired head. :)

Cheers!
Benjamin


--

http://bigbluehat.com/

http://linkedin.com/in/benjaminyoung

________________________________
From: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
Sent: Thursday, July 27, 2017 3:56:43 PM
To: Benjamin Young
Cc: Baldur Bjarnason; W3C Publishing Working Group; Laurent Le Meur; Garth Conboy
Subject: Re: Can a publication change over time?



ServiceWorkers deal with this situation wrt to caches:

https://w3c.github.io/ServiceWorker/#cache-lifetimes

"...caches are not updated automatically. Updates must be manually managed.  This implies that authors should version their caches by name and make  sure to use the caches only from the version of the service worker that can safely operate on."


That seems to map pretty cleanly to the world of WP's where offline-ification is a requirement. Consequently, the Web Publication would become "published" once it lived as close to the reader as possible--in this case, within a unique local cache/storage.

I'm not sure that I understand your point. There's no magic involved with Service Workers. They're pretty much a proxy that you can control using Javascript.

How you handle the network policy ("network then cache" for example) is entirely up to you, same for how the resources are actually cached (which cache key, how you sweep and initialize your cache).

How does this map cleanly to the world of WP?


If the publication were prevented (or asked not to) be kept by the browser/reader, then the publication would "just be a web site" and get updates the same as every web page--"live" upon request...no additional decision to be made.

Are you suggesting that to handle offline use cases we'll have to rely entirely on a Service Worker written by the author?

If that's your suggestion, what's the difference then between a PWA and a WP aside from a potentially different manifest?

IMO, we should have a declarative approach to our resources (list them in the manifest) and I don't think that it's reasonable to expect all WPs to craft their own SW.
Keep also in mind that SWs are still unavailable in Safari (goodbye offline reading on iOS) and in Webviews on Android (only available in Chrome itself).




Just thoughts. :)

Benjamin


--

http://bigbluehat.com/

http://linkedin.com/in/benjaminyoung

________________________________
From: Hadrien Gardeur <hadrien.gardeur@feedbooks.com<mailto:hadrien.gardeur@feedbooks.com>>
Sent: Thursday, July 27, 2017 1:53:24 PM
To: Baldur Bjarnason
Cc: Garth Conboy; Laurent Le Meur; public-publ-wg@w3.org<mailto:public-publ-wg@w3.org>

Subject: Re: Can a publication change over time?

All we can realistically accomplish here is to outline a mechanism where publishers can provide metadata of the sort that Hadrien describes. Even then that’s only going to be advisory/informative since the publisher still has the ability to modify those resources and if the UA is going to reject changed resources we’re basically back to using the SRI spec.

Fully agree that this is at best a hint that could be useful to update the WP when you cache it (offline reading) or package it (PWP). Fairly similar to "updated" in Atom.