- From: Leonard Rosenthol <lrosenth@adobe.com>
- Date: Thu, 7 Jan 2016 02:06:16 +0000
- To: Ivan Herman <ivan@w3.org>
- CC: Daniel Weck <daniel.weck@gmail.com>, Brady Duga <duga@google.com>, "Dave Cramer" <Dave.Cramer@hbgusa.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>
I think this gets us into the “redirection” discussion again - since you may need both a “local” and a “remote” URI for each of these resources. Leonard On 1/6/16, 7:40 AM, "Ivan Herman" <ivan@w3.org> wrote: > >> On 6 Jan 2016, at 12:01, Leonard Rosenthol <lrosenth@adobe.com> wrote: >> >> For any PWP, just as with a web site, there needs to be a “base URI” from which all relative URIs are resolved. It is also the scope/root/origin domain when considering cross-origin requests. >> >> As such, I would certainly expect that for the case of a “fully self-contained” PWP, that all URIs are exist as relative to that origin/base. For any PWP that wants to reach out to external resources, then it can do whatever it wants (modulo CORS or other issues). > >At the moment, there is no such restriction in the definition of a PWP. It is just a set of resources, they may consist of resources on different domains. > >We *may* get to the point where such restrictions becomes necessary, but I am not sure. > >Ivan > >> >> Again, as with other things, let’s not let specific implementations or separate discussions (such as the BFF - browser friendly format) influence the general purpose definitions of a PWP and its RS. We, of course, should insure that we don’t prevent such things. >> >> Leonard >> >> >> >> On 1/6/16, 5:28 AM, "Ivan Herman" <ivan@w3.org> wrote: >> >>> 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 >>> >>> >>> >>> > > >---- >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 Thursday, 7 January 2016 02:06:50 UTC