<!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>At 21:45 -0700 29/07/08, Robert O'Callahan wrote:</div>
<blockquote type="cite" cite>On Tue, Jul 29, 2008 at 11:20 AM, Dave
Singer <<a href="mailto:singer@apple.com">singer@apple.com</a>>
wrote:<br>
<blockquote>Caching is on a full URL basis, of course. Once that
is decided, then yes, I think that pre-cached items for a given URL
are in the general cache for that site.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
A site that uses this feature is likely to be fragile. It will have to
have z.html both in the archive and available directly from the
server, in case z.html is requested before the load of the archive has
finished.</blockquote>
<div><br></div>
<div>No. The definition *for MPEG-21 files* (which is all I have
specified so far) is that accesses to the matching absolute URL (or
relative URL) from within the archibe MUST find the resource within
the archive. Since, as I say, this format starts with a
directory, you know whether you have it or not. If ZIP or JAR
files don't have a directory, then yes, they have a different
trade-off and must load the whole thing before they know.</div>
<div><br></div>
<div>You only need a resource *outside* the archive if it is requested
'nakedly' from outside the archive. If you do that, it might
indeed hurt, but that's your choice as a site.</div>
<div><br></div>
<div>The performance trade-off is very simple; if you have many
small resources it may be much more efficient to ftch them as a
package than individually. The downside is that this is a single
connection in a pre-defined order whereas multiple resources could be
fetched on parallel connections, and as needed. I doubt more
connections to the same server gets you more bandwidth, however, and
the mpeg-21 format also allows extent-based interleaving so that e.g.
a lareg HTML page and and large JPEG can be loaded progressively
together.</div>
<div><br></div>
<blockquote type="cite" cite>And if those copies ever get out of sync
you're in very big trouble, because depending on the context, either
the archive version or the direct version is likely to consistently
win the load race, so just occasionally some clients will get the
wrong version. This seems like a highly error-prone design.<br>
<br>
Rob<br>
</blockquote>
<blockquote type="cite" cite>--<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>
<div><br></div>
<div><br></div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div>David Singer<br>
Apple/QuickTime</div>
</body>
</html>