[Bug 24658] [imports]: The fetch readiness shouldn't block fetching.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24658

--- Comment #5 from Morrita Hajime <morrita@google.com> ---
(In reply to Gabor Krizsanits from comment #4)
> Just one thing... If imports look like this those scripts will be executed
> even if the sub imports are failed to be loaded... If you want to hook up an
> onload function on the import link element, the definition of that onload
> function should be in a script before the subimports in the DOM.
> 
> <head>
> <script>function runMe(){..}</script>
> <link rel=import ... onload="runme()">
> 
> But I might be overlooking something trivial...

Yeah, onload won't be that useful in practice when you use it in the markup
form. I see that onload is used to track asynchronous loading done by
adding <link> dynamically:

link = document.createElement("link");
link.setAttribute("rel", "import");
link.setAttribute("href", url);
link.onload = function() { ... }
document.head.appendChild(head);

> > At the same time, it might be clearer to make it explicit that when we
> > recompute the readiness and unblock parsers. As you are suggesting, it would
> > be when each import finished loading.
> 
> Yes, exactly this is my point. So if I understand correctly we want to
> guarantee a sane script execution order, and block only things that really
> needs to be blocked for it. So how about this:
> 
> Script execution can be blocked in an import two ways, either internally
> during parsing it when a script or an import tag is found, or externally,
> before even we begin parsing it, because there is another import in the tree
> that has to be finished first. This later what we really have to define and
> deal with more now, since the parser will take care of the other first kind
> of blocking.
> 

Ah, having the internal blocking and external blocking separately seems
good idea to explain it. Thanks!

> Instead of that list we could just build up this tree of links whose imports
> might be blocking an external import (a link that is not in their sub import
> tree). So when an import is finished loading we remove it from this tree,
> and check if the left most leaf (we call first child in this tree until we
> find a leaf I mean) in this tree can/has to be unblocked. Kind of equivalent
> with the list version but I find it easier to wrap my head around, so I
> though it worth to be shared.

It's almost tree, except we have import sharing (dedup). de-dup makes
everything complicated. Once we allow import sharing (by having <link>s with
same URL), it is no longer a tree. It becoems DAG, or even could have cycles.
That's why I gave up the tree and use list intead.

But yes, having a list globally makes explanation cryptic
and it kills parallelism easily if misstated.

My current thinking here is that we could prevent cycles explicitly and accept
the notion of DAG somehow.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 14 February 2014 23:32:34 UTC