<div dir="ltr"><div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">Hello again all,<br><br>A couple more comments.<br><br></span></font><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008"><strong>When is anything ever 
deleted?</strong></span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008"></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">Maybe i missed it, but where does appCache deletion 
happen?</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008"></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">Something that Gears user&#39;s have done is to serve an 
empty manifest file. The results are a close approximation to having deleted the 
resource store. I would vote to have&nbsp;some syntax for expressing &#39;delete me&#39;&nbsp; in 
the manifest file for an appCache. A new type of event may be warranted for 
completion of such an update, and when swapCache() is called there&nbsp;would no 
longer an appCache associated with the context.<br><br></span></font><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008"><strong>Should we revisit the caching semantics for any resource 
not explicitly listed in the manifest?<br><br></strong></span></font><div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">Unless i missed something, I think the appCache 
update/validation logic is fundamentally flawed with regard to resources that 
are not explicitly listed. As presently spec&#39;d, a failure to update/validate any 
of these resources&nbsp;causes the entire update to fail,&nbsp;and the old version will 
remain&nbsp;pinned in the cache.&nbsp;Now suppose the app changes it&#39;s url space such that 
some of the&nbsp;resources that got picked up&nbsp;by one of the mechanisms to add new 
resources (autocaching namespace&nbsp;or&nbsp;manually .add()ed or &lt;html 
manifest=x&gt;) no longer make sense... i think this means the appCache is stuck in time.<br></span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008"></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">One idea is to&nbsp;rephrase this&nbsp;feature&nbsp;in terms&nbsp;closer 
to&nbsp;std http caching for all entries that do not explicily appear in the manifest 
file. In effect,&nbsp;closer to telling&nbsp;the&nbsp;http cache to not purge the 
resource.</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008"></span></font><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008"></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">* at initial cache time</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">&nbsp;&nbsp;- cache the resource</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008"></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">* at appCache update time</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">&nbsp; - validate all non-explicit entries per usual http 
caching semantics</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">&nbsp;&nbsp;&nbsp;&nbsp; (so 404s&nbsp; will remove these entries at update 
time)</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">&nbsp;&nbsp;- network/server errors do not fail the larger 
update</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">&nbsp; - beyond that, not sure what todo on network/server 
errors... remove or retain the resources?</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">&nbsp; - perhaps maintain a list of &#39;failed to update&#39; items 
that the webapp can access via script</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008"></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">* at resource load time</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">&nbsp; - validate per usual http caching rules going 
forward</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">&nbsp;&nbsp;&nbsp; (so 404s will remove these 
entries)</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">&nbsp;&nbsp;-&nbsp;with the following&nbsp;exceptions</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">&nbsp;&nbsp;&nbsp;&nbsp; - use the cached resource as a&nbsp;fallback 
</span></font><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">for network or server(5xx) errors</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">&nbsp;&nbsp;&nbsp;&nbsp; - do not&nbsp;purge the resource upon 
expiration<br><br>Comments?<br><br></span></font></div></span></font></div></div><br><div class="gmail_quote">On Mon, Aug 25, 2008 at 11:54 AM, Michael Nordman <span dir="ltr">&lt;<a href="mailto:michaeln@google.com">michaeln@google.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr"><div><font color="#800000" size="2" face="Trebuchet MS"><span>
<h4 style="font-weight: normal;"><span>Hello all,</span></h4>
<h4 style="font-weight: normal;"><span>I have many comments on the Offline Web Applications 
corner of the HTML5 spec. This is the first round of comments you&#39;ll see coming 
from me. This one is mostly top-level comments.<br></span></h4>
<h4><span></span><span></span><span>5.7.2 
</span>Application caches</h4></span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>I found the terminology used to describe the contents of 
the cache&nbsp;sometimes contradictory and confusing, and it doesn&#39;t correspond 
directly with the terminology used in the manifest file syntax. FWIW, some word 
smithing and reconciling the differences could add clarity to the 
spec.</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span><b>
cached resource</b></span></font></font><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span><b> categories</b></span></font></font></div>

<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>&nbsp;&nbsp;</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>* implicit category</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>This categorization applies to html docs which 
explicitly contain a reference to the manifest file via the &#39;manifest&#39; attribute 
of their &lt;html&gt; tag. I understand they are not necessarily&nbsp;explicitly 
listed in the manifest file, but they&nbsp;may also be explicitly listed.&nbsp;The&nbsp;end 
result is that a resource&nbsp;can be categorized as both&nbsp;&#39;implicit&#39; and &#39;explicit&#39;. 
This is confusing. I&#39;d vote to have a&nbsp;different name for clarity sake... some 
ideas... &#39;toplevel&#39;, &#39;manifest referencing&#39;, &#39;native&#39; (an awkward&nbsp;play on 
foreign).</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>* manifest category</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>Perfect.</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>*&nbsp;explicit category</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>Ok provided &#39;implicit&#39; is renamed.</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>*&nbsp;fallback category</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>The term &#39;fallback&#39; refers to the prescribed use of 
these resources for the opportunistic-caching namespace in particular. As part 
of pulling apart namespaces vs how to handle hits within a namespace, I&#39;d vote 
to change the name for this category... some ideas... &#39;namespace-handler&#39;.&nbsp; I&#39;ll 
say more more to say about different types of &#39;namespaces&#39; 
below.</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>* opportunistcally cached category</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>A&nbsp;mouthful, but ok. Another possibility is 
&#39;auto-cached&#39; which would work well with the&nbsp;&#39;manually-cached&#39; terminology 
below.</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>* dynamic category</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>I&#39;d like to reserve the term &#39;dynamic&#39; for a different 
use of that term (more on that in a moment).&nbsp; Some name possibilites for this 
category... &#39;manually-cached&#39; or &#39;script-added&#39; or 
&#39;programatically-added&#39;.</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span><span><b>&nbsp;flavors of namespaces</b></span></span></font></font></div>

<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span><span></span></span></font>&nbsp;</font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span><span>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* online whitelist</span></font></div>

<div><font color="#800000" size="2" face="Trebuchet MS"><span>As mentioned in previous messages, this would need to 
be some form of namespacing or filtering to be useful. A better term for this 
might be &#39;bypass&#39; since with respect to the appcache, hits here bypass the 
cache. Its not clear if path prefix matching is the best option for filtering 
out request that should bypass the cache. In working with app developers using 
Gears, the idea of specifying a particular query argument to filter on in 
addition to a path prefix has come up.<a href="http://server/pathprefix" target="_blank"> http://server/pathprefix</a>&nbsp;&nbsp;&nbsp;+&nbsp; 
&amp;bypassAppCache</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</div></span></span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span><span>* opportunistic caching 
namespaces</span></span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span><span>A mouthful but ok. 
Whatever terminology used for the category of resulting entries should be used 
here... perhaps&nbsp;&#39;auto-caching namespace&#39;.</span></span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* fallback namespace [factored out of 
opportunistic-caching]</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>This form of namespace is addressed by the spec at 
present, but is co-mingled with the auto-caching feature. This is a proposal to 
detangle them from one another. The basic idea is to load the resource as usual, 
and only upon failure fallback to a cached&nbsp;&#39;namespace-handler&#39;... no 
auto-caching involved.</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</div></span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>* intercept namespaces [new]</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>This form of namespace is not in the spec at present. 
This is a proposal to add it.&nbsp;It is a heavily used feature of the Gears 
LocalServer. The basic idea is to intercept requests into this namespace and 
satisfy them with a cached&nbsp;&#39;namespace-handler&#39;&nbsp; without consulting the server. 
</span></font></font></div>

<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>
<div><font color="#800000" size="2" face="Trebuchet MS"><span><b>summary of the above change 
requests</b></span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>Cached resource categories (just name 
changes):</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* toplevel - pages which &lt;html 
manifest=&#39;manifesturlforthisappcache&#39;&gt;</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* manifest - the manifest file</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* explicit - explicitly listed in the manifest 
file</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* namespace-handler - resource which is&nbsp;utilized by a 
name-space</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* auto-cached - resources that have been cached via the 
auto-cache namespace</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* manually-cached - resources that have been cached via 
a javascript call to appCache.add()</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>Namespaces (name changes, refactored things a bit, and 
introduced the &#39;intercept&#39; namespace)</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* bypass - bypasses&nbsp;further lookup within the appcache 
and&nbsp;resorts to&nbsp;the usual&nbsp;resource loading</span></font></div>* intercept - 
doesn&#39;t hit server, serves a cached namespace-handler 
resource</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* autocache - hits server, caches successful response 
for future use, on server errors&nbsp;serves a cached namespace-handler 
resource</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* fallback - hits server, does&nbsp;NOT cache successful 
responses, on server errors serves a cached namespace-handler 
resource</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>Manifest file section headers:</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* BYPASS: list of url 
[namespaces/filters]</span></font></div>* CACHE: list of exact 
[urls]</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* INTERCEPT: list of [urlnamespaces, namespace-handler 
url]</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* AUTOCACHE: list of [urlnamespaces, namespace-handler 
url]</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* FALLBACK: : list of [urlnamespaces, namespace-handler 
url]</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span><b>Scriptlets - or dynamic namespace-handlers [new 
idea]</b></span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>Something we wrestled with in the process of putting 
together the Gears LocalServer was the distinction between</span></font><font color="#800000" size="2" face="Trebuchet MS"><span>&nbsp;intercepting requests for urls</span></font><font color="#800000" size="2" face="Trebuchet MS"><span>&nbsp;and 
identifying the appropiate cached resource for that request. We ended up with a 
declarative manifest file, similar to but different from what is contained in 
this spec. This wasn&#39;t an altogether satisfying answer. The expressiveness of 
the language to match/filter requested urls is limited in Gears and this spec 
shares that same characterization. </span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>Something else we&#39;ve wrestled with in Gears was having 
to do awkward redesigns in corners of a web application in order to &#39;take it 
offline&#39;, single-sign-on for example. In general, anywhere an application relies 
on HTTP features more than HTML to&nbsp;influence navigation or conditional resource 
loading,&nbsp;it&#39;s difficult to address with a static cache.</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>So&nbsp;I&#39;d like to propose extending this spec to 
incorporate &#39;dynamically generated responses&#39;. I think this capability fits into 
this corner of the HTML5 spec because this is most directly useful in the 
&quot;Offline Web Application&quot; scenario. The basic idea is to execute application 
code (script) to produce responses to intercepted resource loads.&nbsp;The 
application code is executed in the background and can formulate a&nbsp;response 
asynchronously.</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>Some handwaving where this could hang off of this 
spec</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* Modify namespace-handlers entries to&nbsp;have an 
attitional attribute to indicate that they are to be executed rather than 
returned</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>And some handwaving at what a scriptlet can 
do...</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* Can read the request headers and POST 
body</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* Can set response status code and headers 
(redirects)</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* Can generate a textual response 
body</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* Can designate a non-executable cached resource to be 
returned in response</span></font></div><span> 
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* Can decide to &#39;bypass&#39; handling of a request and 
defer to the usual resource loading</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* Can decide to perform the usual resource loading, 
but&nbsp;to have&nbsp;the response added&nbsp;to the appCache</span></font></div></span>* Can 
access HTML5Database APIs<br></span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* Can utlize XmlHttpRequest to communicate with a 
server</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>This&nbsp;would&nbsp;obviously be&nbsp;significant addition to the 
spec, but&nbsp;i&nbsp;do&nbsp;think this is worth consideration in the context of &#39;offline 
applications&#39;. Based on observations of app developers wrestling with Gears, 
there have been several pain points. The HTML5ApplicationCache addresses one of them with&nbsp;per-application caches. This addition would address 
the second of them.&nbsp; (Another pain point has been application deployment).<br></span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font>&nbsp;</div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>Am interested in seeing what others 
think of an addition along these lines.<br></span></font></div></span></font></font></div></div>
</blockquote></div><br></div>