W3C home > Mailing lists > Public > public-digipub-ig@w3.org > January 2016

Re: Musings on PWP Offline/Online Modes

From: Daniel Weck <daniel.weck@gmail.com>
Date: Wed, 6 Jan 2016 10:16:05 +0000
Message-ID: <CA+FkZ9G-31KMJRaeFG28fbjrHrjmTTWvsu7mig0+DGheXEFKrA@mail.gmail.com>
To: Brady Duga <duga@google.com>
Cc: Ivan Herman <ivan@w3.org>, Dave Cramer <Dave.Cramer@hbgusa.com>, Leonard Rosenthol <lrosenth@adobe.com>, Nick Ruffilo <nickruffilo@gmail.com>, Tzviya Siegman <tsiegman@wiley.com>, Charles LaPierre <charlesl@benetech.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Hi Brady,
Service Workers can intercept resource requests via "fetch" event
listeners, as long as the URLs originate from within the permitted
scope (which is itself an HTTPS URL). So in fact, intercepting
requests to "external" resources is not possible (i.e. different
domain, or even just URL path outside of the registered scope). Note
that the "fetch" *API* (not the event type) can of course be used to
programmatically emit requests to resources hosted on different
domains (via HTTP CORS, just like XmlHTTPRequest), and this can indeed
be used to populate a cache, or to build a PWP / EPUB zipped package
based on some predefined manifest (i.e. list of well-identified
publication resources).






On Tue, Jan 5, 2016 at 4:39 PM, Brady Duga <duga@google.com> wrote:
> One thing to note regarding service workers - while they can be used to
> cache in this simple case of an image on a different server, I don't think
> they could be used in a more complicated case where resources identify other
> resources. So, if you make a page of your publication be
> http://louvre.com/monalisa.html, which in turn references
> http://louvre.com/monalisa.jpg I don't think it is possible to cache the
> image. Though, I am not an expert on service workers, so my understanding
> could be flawed.
> On Tue, Jan 5, 2016 at 7:44 AM, Ivan Herman <ivan@w3.org> wrote:
>> I think the goal should be somewhere in the middle. I agree that the
>> definition of PWP should be, as much as possible, implementation agnostic,
>> but I agree with Dave that saying "we don't care" is also not appropriate.
>> We may have to define a PWP Processor in the abstract sense. What a
>> processor is supposed to do to answer to different use cases, what are its
>> functionalities, that sort of things. We may not define it in a normative
>> way in the sense of some formal language or terminology, but we have to
>> understand what can, cannot, should, or should not be done with a PWP. And
>> it is certainly important to know whether the realization of such a PWP
>> processor is possible with today's technologies, what is PWP specific and
>> what can be reused off the shelf, etc.
>> Ivan
>> On 5 Jan 2016, at 16:24, Cramer, Dave <Dave.Cramer@hbgusa.com> wrote:
>> On Jan 5, 2016, at 9:41 AM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>> Nick – the specifics of how an RS chooses (or not) to cache are out of
>> scope for PWP.  They may make sense for some sort of format-specific work
>> (eg. best practices for PWP with EPUB) but we don’t care about it here.
>> Remember – PWP is format/packaging and implementation agnostic.   (we
>> seemed to all agree to that pre-holidays)
>> The fact that an existing web technology can solve a critical use case for
>> PWP is on-topic in my opinion, and learning about such things can only help
>> our work. Such technologies may not be a part of the documents we produce,
>> but saying "we don't care about it here" I think sends the wrong message.
>> Dave
>> 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 Wednesday, 6 January 2016 10:16:58 UTC

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