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

Re: follow up on service workers for publishing platform

From: Ivan Herman <ivan@w3.org>
Date: Tue, 1 Dec 2015 17:50:00 +0100
Cc: Tzviya Siegman <tsiegman@wiley.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Message-Id: <935F941D-B243-4C55-B042-1C0DE97DB9C3@w3.org>
To: Dave Cramer <Dave.Cramer@hbgusa.com>

> On 1 Dec 2015, at 16:14, Cramer, Dave <Dave.Cramer@hbgusa.com> wrote:
> On Dec 1, 2015, at 9:44 AM, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>> wrote:
>> Let me try to be a little bit more specific for this one. PWP being a kind of a conceptual thingy, I think what we have to talk about is what would we have to see in a manifest *representing* a PWP. What are the information that we need to get the whole architecture running?
>> (We have a reference to manifests and their importance in the document, but it is only a skeleton without meat:-)
> In the Acme Publishing example, the manifest exists only to tell the service worker what files to cache to allow offline reading.

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've also been experimenting with using the web application manifest spec [1]  to gain some additional functionality:
> 1. Allowing a publication to be saved to the home screen (maybe Santa will bring me an android device so I can test this)
> 2. Providing a title and icon for such a publication.
> 3. Defining which file should be opened first when a publication is saved (start_url)
> 4. Hinting at an appropriate display mode
> 5. Defining related applications (could the publications be opened in a formal ebook reading system app?)
> 6. Defining a preferred orientation for the publication (such "rendering metadata" is common in EPUB3 Fixed Layout).
> and so on.
> I'd love to see more concrete examples of what functions a manifest must serve.
> Thanks!
> Dave
> [1] http://www.w3.org/TR/appmanifest/ <http://www.w3.org/TR/appmanifest/>This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.

Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

Received on Tuesday, 1 December 2015 16:50:16 UTC

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