Re: Can a publication change over time?

It might be important for certain applications that a web publication not
change, but I don’t think that’s a spec’s concern is it? There are plenty
of WP applications that you would expect to change over time, and plenty of
WP applications we can’t even imagine yet.

My plea would be for us to focus on developing a minimum viable
definition/spec … the bare minimum need to say: is this a WP? Yes/no? A WP
should be as easy as possible to make a WP.

And then as publishers need certain functionality, they can build that into
their WPs, which can work its way into the spec if enough publishers agree.

On Thu, Jul 27, 2017 at 3:56 PM, Hadrien Gardeur <
hadrien.gardeur@feedbooks.com> wrote:

>
> 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>
> *Sent:* Thursday, July 27, 2017 1:53:24 PM
> *To:* Baldur Bjarnason
> *Cc:* Garth Conboy; Laurent Le Meur; 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.
>
>
>


-- 
--
Hugh McGuire
https://rebus.community
+1.514.464.2047