Re: Musings on PWP Offline/Online Modes

Hi Daniel,

> On 6 Jan 2016, at 11:16, Daniel Weck <daniel.weck@gmail.com> wrote:
> 
> 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).

Just for my understanding: does it meant that, for a specific PWP, the (SW based) RS has to 'register' a number of domains or URL-s in its scope in order to be able to catch the requests and cache the content? If so then, in practice, we are close to the idea that a GET to a PWP should return (some form of) a manifest with the resources the PWP contains which should then be "registered" by the RS.

What bothers me a bit is that, in [1], it talks about *a* 'scope URL'. Does it mean that, by default, the URL-s that are used by a PWP should all be under the same, fixed scope, and we must have a redirection mechanism built in to provide an access to external resources (using the fetch API)?

This does have to shape our thinking, if this is all true.

Thanks

Ivan

[1] http://www.w3.org/TR/service-workers/#dfn-scope-url

> 
> References:
> 
> http://www.w3.org/TR/service-workers/#dfn-scope-url
> 
> https://github.com/jakearchibald/ebook-demo/blob/gh-pages/publisher-site/sw.js
> 
> https://github.com/jakearchibald/ebook-demo/blob/gh-pages/reader-site/sw.js
> 
> Regards,
> Daniel
> 
> 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
>>> 
>>> 
>>> 
>>> 
>> 


----
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