<div class="gmail_quote"><font size="1">(Adding in some of the people involved with Resource Packages earlier to this thread, so they can help me out — I'm just a lowly UI designer, so some of these questions have to be answered by people that know how browsers work. I'm just the messenger. Hope you don't mind, guys, and remember that webkit-dev requires you to sign up before you can post.)</font><br>
<br>On Tue, Nov 17, 2009 at 2:44 PM, Peter Kasting <span dir="ltr"><<a href="mailto:pkasting@google.com" target="_blank">pkasting@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div>I have read the whole document, but I read it quickly, so please do point out places where I've overlooked an obvious response.</div></div></blockquote><div><br>This is what everyone does, so no worries, happy to clarify. 95% of the "this is why this won't work" statements are actually answered by the article in some way. But I guess I shouldn't be surprised. :)<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote">
<div>Reduced parallelism is a big concern of mine. Lots of sites make heavy use of resource sharding across many hostnames to take advantage of multiple connections, which this defeats.</div></div></blockquote><div><br>
If you package up everything in a single zip file, yes. Realistically, if you have a lot of resources, you'd want to spread them out over several files to increase parallelism. Also, there's usually resources that are page-specific (e.g. belong to the article being rendered). As with everything, there are possibilities to use this the wrong way, and packaging up everything in one zip file will definitely affect parallelism. Don't do that.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>I am concerned about the instruction to prefer the packaged resources to any separate resources. This seems to increase the maintenance burden since you can never incrementally override the contents of a package, but always have to repackage.</div>
</div></blockquote><div><br>This is something we could look at, of course. There are easy ways to invalidate the zip using ETags etc.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote">If an author has resources only used on some pages, then he can either make multiple packages (more maintenance burden and exacerbates problem above), or include everything in one package (may result in downloading excessive resources for pages where clients don't need them).</div>
</blockquote><div><br>I don't think it's unreasonable to expect most big sites to have a standard core of resources they use everywhere. It's important not to try to put *everything* in resource packages, just the stuff that should be present everywhere (and the specialized thumbnail search result case I mentioned).<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote">
<div>You note that SPDY has to be implemented by both UAs and web servers, but conversely this proposal needs to be implemented by UAs and _authors_. I would rather burden the guys writing Apache than the guys making webpages, and I think if a technique is extremely useful, it's easier to get support into Apache than into, say, 50% of the webpages out there.</div>
</div></blockquote><div><br>There's no damage if you <i>don't</i> do this as a web author. If you care enough to do CSS spriting and CSS/JS combining, this gives you a more maintainable, easier, faster solution.<br>
<br>On Tue, Nov 17, 2009 at 3:00 PM, James Robinson <span dir="ltr"><<a href="mailto:jamesr@google.com" target="_blank">jamesr@google.com</a>></span>
wrote: <blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote"><div>It seems like a browser will have to essentially stop
rendering until<br>
</div>
it has finished downloading the entire .zip and examined it.</blockquote><div><br>No. That's why the manifest is there, since it can be read early on, so the browser doesn't have to block.<br><br>I see a lot of "I don't think this will work" or "I don't think this will be any faster" here. I guess I should get someone to help me create some reasonable benchmarks and show what the difference would be. Maybe Steve Souders or someone else that is better at this stuff than me can help out with some data.<br>
<br>On Tue, Nov 17, 2009 at 3:02 PM, Peter
Kasting <span dir="ltr"><<a href="mailto:pkasting@google.com" target="_blank">pkasting@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div>I think mitigating this is why there are optional manifests.
I agree that if there's no manifest, this is really, really painful.
I think manifests should be made mandatory.</div></div></blockquote><br>The manifests *are* mandatory. Without a manifest, it won't do anything (ie. proceed to load the resources as usual), since that would block page loads, which is not an option.<br>
<br><br>
On Tue, Nov 17, 2009 at 3:12 PM, Simon
Fraser <span dir="ltr"><<a href="mailto:simon.fraser@apple.com" target="_blank">simon.fraser@apple.com</a>></span> wrote:<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
<div>If
you require a manifest, why not pick an archive format where there's a
TOC which is guaranteed to be at the head of the file, which the browser
can parse without having to wait for the entire file to download?</div></blockquote><div><br>If there are other formats that can a) be streamed and unpacked in partial state, and b) is common enough that people will actually be able to use it, let me know.<br>
<br>The tar format is sequential, and (I think) has the header first, but doesn't do compression. If you add gzip to that, you can't partially unpack, which will block page downloads. You could of course argue that using only tar (without gzip) could work, and I think we're open to supporting that, if those assumptions are correct — I haven't looked at the details for that yet.<br>
</div><br>-- <br>Alexander Limi · Firefox User Experience ·
<a href="http://limi.net" target="_blank">http://limi.net</a><br><br></div></div></div>