On Tue, Aug 26, 2014 at 5:45 PM, Ilya Grigorik <igrigo...@gmail.com> wrote:
> [[stuck in the mod queue.. attempt #5, apologies for dupes if you get
> them]]
>
> Ian, thanks for writing this up.
>
> The first thing that strikes me about this entire topic is its scope, and
> I'm wondering if we should take a step back and (a) extract some lower
> level primitives, (b) leave the rest to libraries and web developers to
> experiment with, and (c) if (b) leads to some good patterns, then codify
> them at a later date... Instead of trying to tackle all of this at once.
>
> In particular, it seems like we might be coupling two topics:
> (1) a flexible declarative mechanism to fetch arbitrary resources
> (2) some set of mechanisms to express dependencies, execution order, etc.
>
> If we do our job right with (1), I think (2) can (should?) be deferred to
> developers and library writers.
>
> Specifically, for (1):
> - We need a way to initiate arbitrary downloads that doc + preload parsers
> will understand and can process
> - We need a way to communicate type, prioritization, MQ, and other custom
> fetch information for each download
> - We need a way to listen on download progress of these resources to build
> custom processing logic
> - By default there is no UA processing on the response, this mechanism
> simply fetches bytes
>
> This is the direction I was proposing earlier [1] with rel=preload -- see
> [2], for a concrete example.
>
> I really like your proposal for "as="... Concretely it could look something
> like this:
>
> <link rel="preload"
> href="/some/asset.css"
> as="stylesheet" (used to initialize default priority, headers,
> etc)
> load-settings="{}" (JSON payload with custom headers, priority
> [2], etc)
> media= "..." (relevant media queries..)
> probability="" ([0.0-1.0] used for speculative fetches [3])
> >
>
> The combination of all of the above allows me to fetch any content-type,
> specify custom priorities and headers (or use a default set via 'as'),
> apply MQ's, etc. Given all that, assuming I can extract a Promise/Fetch
> object (or some such) out of it, I can then track the download progress and
> apply any arbitrary logic for how and when it should be processed. For
> example:
>
> - I can execute a script immediately by waiting for the download to finish
> and inject the script tag referencing same URL
> - I can setup a callback that waits for any other arbitrary resource to
> finish before I execute it...
> - I can defer execution until a particular action occurs.
> - I can prefetch arbitrary resources for later use
> - ...
>
> (note: the script example is completely arbitrary.. the entire point is
> that this mechanism is independent of content-type)
>
> In other words, it seems like you could build most (all?) of the doc'ed use
> cases in client-land...
One thing you won't have here is the declaration of a dependency tree to
the preloader, so e.g. all of your scripts will be of the same priority,
even if some of them depend on others.
I can implement needs, loadPolicty, addDependency
> on my own. Which, in my books, is a much better outcome anyway because it
> will allow more and much more rapid experimentation.
>
> ---
>
> [1]
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-August/297383.html
> [2]
>
> https://docs.google.com/presentation/d/1Q-7keKXwP2UeZ2zTN9Ue2ASIdIZPqxnEvnDsPSLTwcQ/present#slide=id.g377330538_0345
> [3]
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-August/297437.html
> [4]
>
> https://docs.google.com/presentation/d/1Q-7keKXwP2UeZ2zTN9Ue2ASIdIZPqxnEvnDsPSLTwcQ/present#slide=id.g120f70e9a_025
>
