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

Re: follow up on service workers for publishing platform

From: AUDRAIN LUC <LAUDRAIN@hachette-livre.fr>
Date: Wed, 2 Dec 2015 07:37:21 +0100
To: Leonard Rosenthol <lrosenth@adobe.com>, Ivan Herman <ivan@w3.org>, Daniel Weck <daniel.weck@gmail.com>
CC: Dave Cramer <Dave.Cramer@hbgusa.com>, Tzviya Siegman <tsiegman@wiley.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Message-ID: <D2845017.60A87%laudrain@hachette-livre.fr>
Good point. Count me in.
Luc





Le 02/12/2015 06:18, « Leonard Rosenthol » <lrosenth@adobe.com> a écrit :

>At some point, this group should probably start a subgroup focused on
>various font-related issues as there are a number of both technical and
>legal issues that come up in the content of non-packaged publications and
>their use of fonts.
>
>Leonard
>
>
>
>
>On 12/1/15, 9:09 AM, "Ivan Herman" <ivan@w3.org> wrote:
>
>>
>>> On 1 Dec 2015, at 18:03, Daniel Weck <daniel.weck@gmail.com> wrote:
>>> 
>>> 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.
>>
>>Absolutely.
>>
>>> 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).
>>
>>Right. But, additionally, I think providing some level of content
>>provider option may be necessary (inclusion patterns, exclusion
>>patterns, etc.).
>>
>>We used this example before: a publication may refer to very large font
>>files. In some cases, those fonts are for fanciness; ie, it is perfectly
>>o.k. if the reader does not cache those and, in case it is offline,
>>falls back to some system fonts. In other cases those fonts are
>>essential because, for example, they display mathematical symbols or
>>musical notes: in this case the font must be cached, too, for proper
>>offline use. This cannot really be covered algorithmically; it is up to
>>the creator of the publication to control this.
>>
>>Ivan
>>
>>
>>> Dan
>>
>>
>>----
>>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 Wednesday, 2 December 2015 06:37:51 UTC

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