On Apr 22, 3:36 pm, Aryeh Gregor <simetri
...@gmail.com> wrote:
> Surely you could compute the last applicable resource-package for a
> given resource during parsing? Then you'd just have to read off the
> last resource-package parsed at that point.
I suppose we could keep a list of the seen resource packages while
parsing. But a DOM node can trigger a resource load even after the
document has finished parsing (say, an <img>'s href is changed by a
script), so this doesn't help us too much.
Walking the <head> is probably fine if we only have to do it for
resources linked from the <head>. I need to see.
> > I'd also need to specify that for resources not in the DOM (e.g.
> > Javascript Image()s), we use the set of resource packages present when
> > that object is fetched.
> Is that even deterministic? (No hope for it if it's not, I guess.)
Yeah, I'm not sure there's much hope. At least it's well-defined,
even if it's unpredictable. :)
> If a resource is in the
> cache but the copy from the resource-package is functionally
> different, the site is buggy regardless -- some users will be randomly
> getting the old copy from cache and some will be getting the new copy,
> no matter what. Or if the resource-package is out of sync with the
> actual files, some browsers will be getting one version and some the
> other. Adding further unpredictability in this case is not a huge
> cost AFAICT.
I haven't been around for too long, but I thought that the lesson of
HTML5 was that ambiguity should be avoided at most costs; it's most
important that all browsers work the same way, even in error cases.
I can think of some situations where a more relaxed cache policy might
be nice. For instance, if the browser already has script.js in the
cache from a page which didn't use resource packages, the browser
doesn't need to wait until the resource package has downloaded before
it can start running script.js.
But in reality, if the site is using resource packages, it should just
use resource packages everywhere. With the strict cache policy, we'll
experience a slowdown relative to the relaxed cache policy exactly
once, on the first visit to a page with resource packages.
Similarly, you probably wouldn't provide a file in two separate
resource packages, at least not on purpose. So I'm not convinced that
the slowdown we get here by saying that we always wait for the last
package to download is worth the loss of consistency of saying that we
can load a resource from whichever package we want.
> A further thought: what's the story on what happens if an author
> doesn't provide content="" or a manifest? ZIP puts the list of files
> at the end, so all resource loads will be blocked until the ZIP is
> fully read in this case, no?
> If there's some common format that wouldn't need a manifest, it would
> be a good idea to standardize on that format and ban others.
I'm not aware of any common format that wouldn't require a manifest.
tar.gz files actually don't contain a dictionary at the end; to get a
complete list of a .tar.gz's files, you have to extract the whole
tarball. (At least, this is what I understand I'm not 100% sure
that's right; I haven't implemented tar.gz yet.)
Having said this, one can obviate the whole problem by putting the
resource package inside a subdirectory. If the package is located at /
static/pkg.zip, then only loads from the /static directory will block
on the resource package, even if it doesn't contain a content
attribute or a manifest. Whether or not developers will do that is
another story.
Even if we changed the semantics of loading to let browsers ignore
resource packages whenever they wanted, I think most browsers will
block optimistically when they see a resource package which might
contain a resource they want. The alternative it to be pessimistic
and assume the resource package doesn't contain what you want, but in
that case, why implement resource packages at all?
One last thing: If the content attribute is explicitly set to "", the
spec currently says that the browser treats the resource package as if
it's empty.
