<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [whatwg] Application
deployment</title></head><body>
<div>The situation is a lot better for archives (like MPEG-21 files)
that have a directory at the front...</div>
<div><br></div>
<div><br></div>
<div>At 20:10 -0400 29/07/08, Russell Leggett wrote:</div>
<blockquote type="cite" cite>
<blockquote>That is a performance killer.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>I don't think it is as much of a
performance killer as you say it is. Correct me if I'm wrong, but the
standard connection limit is two. It is not as though every external
file could be loaded at once. Additionally, as I said, you could split
resources into multiple archives to take advantage of multiple
connections, because they can be loaded asynchronously without issue.
Remember, the use case for this would be when there are likely
dozens of different files that need to be loaded.</blockquote>
<blockquote type="cite" cite><br>
<blockquote>So you get nondeterministic load behaviour anyway. This is
not good.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>This is not so different than directly
requesting a file from multiple tabs. Let's say page 1 and page 2 each
use the same image. If I load page 2 first, it will go directly to the
server. If I load page 1 first, page 2 will get the image from
cache.<br>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>Clearly, there are other ways of
performing this task, but I think this way is simple and I know that I
would gladly accept it as a possibility. It falls within the same
realm that any caching behavior does. It is meant purely for
performance, but if you are relying on it for a given behavior then
you are on a road to trouble.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>The archived resources should be static,
and also available as individual files. Pre-fetching them
should only be used for performance gains, and if it would not be
performant, it should not be used. However, I think there is a fairly
wide range of sites or applications that could benefit from this
feature. If there are other ways of improving it, or making it work
better for certain edge cases, that would be great, but don't throw
the baby out with the bath water.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>Off the top of my head, I can think of a
couple of ways to refine the feature and deal with the issues
raised.<br>
</blockquote>
<blockquote type="cite" cite>
<ul>
<li>Only blocking the loading of files that could logically be inside
the archive: if the archive is located at
"/js/resources.zip", then the only files that should be
blocked would have to be located under "/js". <img
src="/images/lolcat.jpg"/> would not be blocked.
<li>To go a step further, there could even be some kind of
"pattern" attribute that would block the loading of files
that matched a url pattern. For example, if the archive were located
at "/", but had a pattern of
"**.js,**.css,/images/*", only js, css, and files under the
"/images" directory would be blocked.</ul>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>On Tue, Jul 29, 2008 at 2:13 PM, Robert
O'Callahan <<a
href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>>
wrote:<br>
<blockquote>On Tue, Jul 29, 2008 at 5:59 AM, Russell Leggett <<a
href="mailto:russell.leggett@gmail.com">russell.leggett@gmail.com</a>>
wrote:<br>
<blockquote>Yes, the one major hang up that I foresee is how
a browser should handle asynchronous loading. How would it know the
contents of the archive before it loaded the archive so it did not try
to load the same files directly? The simple answer would be to load
the archive(s) synchronously.<br>
</blockquote>
</blockquote>
<blockquote> <br>
That is a performance killer.<br>
<blockquote>As for references in a different tab, if the separate
tab/document did not reference the zip archive first, it would operate
as normal. It would check the cache and then attempt to load. If the
zip had been loaded from the first page already, the file would be
present in the cache, and if not, then the browser would attempt to
retrieve it from the server.<br>
</blockquote>
</blockquote>
<blockquote><br>
So you get nondeterministic load behaviour anyway. This is not
good.<br>
</blockquote>
<blockquote>Rob<br>
</blockquote>
<blockquote>--<br>
"He was pierced for our transgressions, he was crushed for our
iniquities; the punishment that brought us peace was upon him, and by
his wounds we are healed. We all, like sheep, have gone astray, each
of us has turned to his own way; and the LORD has laid on him the
iniquity of us all." [Isaiah 53:5-6]</blockquote>
</blockquote>
<div><br></div>
<div><br></div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div>David Singer<br>
Apple/QuickTime</div>
</body>
</html>