Re: [whatwg] resource hints and separating download from processing

+1 to breaking the dependency between fetching the resource and how it is later used in the document. This type of “late binding” enables many page optimizations.

Peter

PS. My apologies if you’ve already seen a message saying similar. I’m not sure if the mailing list is accepting my messages or not yet.

On Aug 8, 2014, at 2:17 AM, Ben Maurer <ben.maurer@gmail.com> wrote:

> Sweet, I think we're on the same page. I completely agree with your high
> level goal of a declarative fetch interface.
> 
> Agreed that matching is still critical, eg for the Link header use case.
> 
> 
> On Thu, Aug 7, 2014 at 10:40 PM, Ilya Grigorik <igrigorik@gmail.com> wrote:
> 
>> 
>> 
>> 
>> On Thu, Aug 7, 2014 at 4:39 PM, Ben Maurer <ben.maurer@gmail.com> wrote:
>>> 
>>> On Thu, Aug 7, 2014 at 3:21 PM, Ilya Grigorik <igrigorik@gmail.com>
>>> wrote:
>>> 
>>>> 
>>>> It would be nice if there was a more declarative relationship between
>>>>> the declarative fetch and the eventual use of the resource (assuming the
>>>>> resources are on the same page).
>>>>> 
>>>> 
>>>> I would like to break that dependency. I want layering separation where
>>>> we have a clean way to fetch resources (with custom parameters like
>>>> headers, priorities, dependencies, etc), and a layer that's responsible for
>>>> consuming fetched resources for processing in the right context (enforcing
>>>> security policies, etc), and at the right time -- e.g. see Example 3 under:
>>>> https://igrigorik.github.io/resource-hints/#preload
>>>> 
>>> 
>>> So I guess my worry here is that the loose dependency could be hard to
>>> debug. As a concrete example, we use crossorigin=anonymous on our <script>
>>> tags so that we can get stack traces. My understanding is that this
>>> requires an Origin header to be sent with the request and a CORS header in
>>> the response. If my  <link rel="preload" doesn't have a crossorigin
>>> setting, the requests wouldn't match up.
>>> 
>> 
>> We can't control the response bits, but as far as emitting the right
>> request headers and communicating stream priority + dependencies, all of
>> that could be exposed via some set of options when the request is built up.
>> This is where we get back to the syntax (e.g. params="{...}", or some
>> such), which would probably map directly to various Fetch API use cases and
>> options. Effectively, I want a declarative Fetch interface.
>> 
>> 
>>> I guess what I'm asking for here is some programmatic way of connecting
>>> the fetch with the consumption. For example, exposing the fetch object of
>>> the rel=preload and allowing you to construct a script tag explicitly with
>>> the fetch object.
>>> 
>> 
>> +1. That said, we still *need* a mechanism where the matching does not
>> rely on manual plumbing with JavaScript - e.g. server returns a set of
>> hints via Link header for critical resources, which must be matched by the
>> user agent against appropriate requests later in the doc.
>> 
>> ig
>>

Received on Friday, 8 August 2014 12:14:57 UTC