[whatwg] Application deployment

[Russell Leggett]

>
> So if I load http://www.example.com/x.m21#y.html<http://www.example.com/x.m21#y.html*q> and
> (in the same document, or in another tab?) load
> http://www.example.com/z.html, and x.m21 contains a z.html but the server
> also responds to http://example.com/z.html, does the second load (z.html)
> come from the server or the container? Does it depend on whether the second
> load starts before the first load finishes?
>
> The same questions apply to Russell's proposal.


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. In my previous
example:

<link rel="resources" href="/js-files.zip"/>

<script type="text/javascript" src="/js/file1.js"></script>
<script type="text/javascript" src="/js/file2.js"></script>
<script type="text/javascript" src="/js/file3.js"></script>
<script type="text/javascript" src="/js/file4.js"></script>
<script type="text/javascript" src="/js/file5.js"></script>

The browser could begin loading the zip, and during the load wait before
loading any other files. In an effort to take advantage of multiple
connections, multiple archives could be used. Multiple archives could be
loaded asynchronously without issue.

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.

My proposal is only intended as a way to make HTML work the way it was
intended and remain efficient.  CSS sprites and concatenated scripts are
assumed for any high performance site, but they add an unnecessary level of
complexity. Other suggestions such as HTTP pipelining and the jar protocol
are more complex and out of scope of the HTML5 specification. I think my
proposal degrades gracefully, and while I am not a browser manufacturer, it
seems relatively simple to implement.

Russ

On Tue, Jul 29, 2008 at 3:51 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Tue, Jul 29, 2008 at 8:02 AM, Dave Singer <singer at apple.com> wrote:
>
>>
>> c) that the contents of the container, once fetched and un-packed,
>> logically 'shadow' the directory where the container came from.
>>
>
> It sounds like that affects all loads, which leads to issues:
>
> So if I load http://www.example.com/x.m21#y.html<http://www.example.com/x.m21#y.html*q>and (in the same document, or in another tab?) load
> http://www.example.com/z.html, and x.m21 contains a z.html but the server
> also responds to http://example.com/z.html, does the second load (z.html)
> come from the server or the container? Does it depend on whether the second
> load starts before the first load finishes?
>
> The same questions apply to Russell's proposal.
>
> 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]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080729/2051da8b/attachment.htm>