[Bug 24564] [Imports]: Blocking circular reference in the import tree/list

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

Morrita Hajime <morrita@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |esprehn@gmail.com

--- Comment #11 from Morrita Hajime <morrita@google.com> ---
(In reply to Gabor Krizsanits from comment #10)
> Hmmm... the latest version seems very promising so far. I have a few
> concerns regards of performance, but I think we should focus first on the
> right behaviour and this version is pretty clear in that respect. I guess
> the only part I'm not sure is, why do we need to block fetching (fetch
> readiness) instead of just block script execution in the very same way as
> the algorithm describes (just with 'ready for script execution' flag in the
> list). Is there a reason why in your example c should not be fetched/parsed
> with its scripts blocked before b is done? 

I spec-ed that the readiness blocks fetching so that
the shape of the import-link-list deterministic.

Think about

* index.html
  <link id=li0 rel=import href="a.html">
  <link id=li1 rel=import href="b.html">
* a.html
  <link id=la rel=import href="b.html">
* b.html
  <link id=lb rel=import href="c.html">
* c.html
  ...

In this case, import-link-list could have either:

- [li0, la, li1, lb]
- [li0, la, lb, li1]

depends on which of li0 or la fetches b.html. I don't want to have this
undeterminisity.

However, I now realized that this shouldn't be a problem in practice. I think
this is a spec problem that says loading should be fully ordered by stating
that there is a import-link-list.

The spec should say, instead, that loading should be partially ordered. Then we
no longer need to block fetching but can only block scripting  as you
mentioned. I'd be done by employing other data structure than a list. 

So thanks for the clarification! I'll file a bug to address this.

> 
> The other part is not entirely clear how all these algorithms in the spec
> work together exactly. More specifically when should one check for fetch
> readiness? Every time an import finishes we find the next candidate that can
> be fetched?

Yes, this is kinda reactive thing. In Blink, the readiness of each import is 
re-evaluated each time when any one import finished loading.

I hope there are better way to explain this nature but I have no idea so far.
Suggestions are welcome!

> 
> One thing for the map. I wonder if it would make sense to make it a
> <location, loader> map instead of a <location, import document>. But I guess
> this is more like an implementation detail...
>

Yeah, the underlying conceptual model here is exactly what you are suggesting.
I use document as a proxy of loader because we have no such abstraction like
loader.

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

Received on Thursday, 13 February 2014 21:31:42 UTC