Integrating the Webs' dependency systems
Anne van Kesteren
annevk at annevk.nl
Wed May 28 03:13:55 PDT 2014
On Wed, May 28, 2014 at 12:29 AM, Kris Kowal <kris.kowal at cixar.com> wrote:
> On Tue, May 27, 2014 at 3:04 PM, Ian Hickson <ian at hixie.ch> wrote:
>> On Tue, 27 May 2014, Kris Kowal wrote:
>>> It would be lovely if HTML could be trained to resolve URL's through the
>>> module system.
>> By "HTML" here I presume you mean the underlying Fetch mechanism. Could
>> you elaborate on exactly how this would work? Would this be in the layer
>> before or after Service Workers?
> Supposing that a page has both a service worker and a custom loader, I would
> expect all requests for URL’s in the page (href, src, etc) to
> 1. pass through the page’s loader
> 2. pass through the browser's fetch mechanism
> 3. pass through the service worker
Only http/https URL fetches enter the service worker.
> 4. pass through the browser's fetch mechanism again
This depends on what the service worker does. It might instead perform
its own fetches (using fetch()) which presumably would go through the
service worker's loader if we were to define that as such (it having
its own global environment). The service worker might also pop back up
to fetch and let it handle the fetch (not handling the fetch event) or
might indeed pass it through fetch (using event.default()). It might
also return a generated response or some such.
> 5. possibly arrive at the true service
The HTTP layer you mean I guess.
> 6… proxies all the way down?
I suppose you could further divide the HTTP layer.
More information about the es-discuss