W3C home > Mailing lists > Public > public-digipub-ig@w3.org > December 2015

Re: follow up on service workers for publishing platform

From: Daniel Weck <daniel.weck@gmail.com>
Date: Tue, 1 Dec 2015 17:03:46 +0000
Message-ID: <CA+FkZ9HEqFC+Dm2q=6k2jcuK+Jaq8BXqRsBodDH5=5Le=_5t3Q@mail.gmail.com>
To: Ivan Herman <ivan@w3.org>
Cc: Dave Cramer <Dave.Cramer@hbgusa.com>, Tzviya Siegman <tsiegman@wiley.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
On Tue, Dec 1, 2015 at 4:50 PM, Ivan Herman <ivan@w3.org> wrote:
> I understand this for Acme. However, thinking it further in direction of a
> more sophisticated reader: is it necessary to store all the file references?
> After all, I would expect the Service Worker may find out on the fly that a
> resource is to be cached.
> This may be important for the production site. This means I do not have to
> list the references of all the images, js and css files, etc, just the 'top
> level' files to trigger the process and those could be cached.
> Of course, there is a danger that the reader would cache too much, eg,
> remote references that the content refers to. So maybe the manifest could
> contain some sort of URI patterns, saying to the reader: "if the URI matches
> one of these patterns, cache it".

I would assume that all of the reading system's app resources would be
cached "immediately" (i.e. as early as possible in the bootstrap
process), so that the reading system itself is available offline.
However, publication content would be cached according to a particular
strategy (on-demand vs. preload, LRU eviction, etc.), in terms of
offline-ing multiple publications, but also in terms of offline-ing
resources within a given publication (partial fetch vs. full cache).
Received on Tuesday, 1 December 2015 17:04:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:20 UTC