[whatwg] Application deployment

[Dave Singer]

The situation is a lot better for archives (like MPEG-21 files) that 
have a directory at the front...


At 20:10  -0400 29/07/08, Russell Leggett wrote:
>That is a performance killer.
>
>
>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.
>
>So you get nondeterministic load behaviour anyway. This is not good.
>
>
>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.
>
>
>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.
>
>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.
>
>Off the top of my head, I can think of a couple of ways to refine 
>the feature and deal with the issues raised.
>
>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.
>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.
>
>On Tue, Jul 29, 2008 at 2:13 PM, Robert O'Callahan 
><<mailto:robert at ocallahan.org>robert at ocallahan.org> wrote:
>
>On Tue, Jul 29, 2008 at 5:59 AM, Russell Leggett 
><<mailto:russell.leggett at gmail.com>russell.leggett at gmail.com> wrote:
>
>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.
>
>
>That is a performance killer.
>
>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.
>
>
>So you get nondeterministic load behaviour anyway. This is not good.
>
>Rob
>
>--
>"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]


-- 
David Singer
Apple/QuickTime
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080729/7e25bfac/attachment-0001.htm>