<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> </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> </div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">Something that Gears user'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 some syntax for expressing 'delete me' 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 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'd, a failure to update/validate any
of these resources causes the entire update to fail, and the old version will
remain pinned in the cache. Now suppose the app changes it's url space such that
some of the resources that got picked up by one of the mechanisms to add new
resources (autocaching namespace or manually .add()ed or <html
manifest=x>) 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> </div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008">One idea is to rephrase this feature in terms closer
to std http caching for all entries that do not explicily appear in the manifest
file. In effect, closer to telling the 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> </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"> - cache the resource</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008"></span></font> </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"> - 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"> (so 404s will remove these entries at update
time)</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008"> - 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"> - 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"> - perhaps maintain a list of 'failed to update' 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> </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"> - validate per usual http caching rules going
forward</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008"> (so 404s will remove these
entries)</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008"> - with the following exceptions</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span class="627414118-29082008"> - use the cached resource as a 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"> - do not 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"><<a href="mailto:michaeln@google.com">michaeln@google.com</a>></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'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 sometimes contradictory and confusing, and it doesn'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> </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> </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 'manifest' attribute
of their <html> tag. I understand they are not necessarily explicitly
listed in the manifest file, but they may also be explicitly listed. The end
result is that a resource can be categorized as both 'implicit' and 'explicit'.
This is confusing. I'd vote to have a different name for clarity sake... some
ideas... 'toplevel', 'manifest referencing', 'native' (an awkward 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> </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> </font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>* 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 'implicit' 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> </font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span>* 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 'fallback' 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'd vote
to change the name for this category... some ideas... 'namespace-handler'. I'll
say more more to say about different types of 'namespaces'
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> </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 mouthful, but ok. Another possibility is
'auto-cached' which would work well with the 'manually-cached' 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> </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'd like to reserve the term 'dynamic' for a different
use of that term (more on that in a moment). Some name possibilites for this
category... 'manually-cached' or 'script-added' or
'programatically-added'.</span></font></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span></span></font> </font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><font color="#800000" size="2" face="Trebuchet MS"><span><span><b> 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> </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 'bypass' 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> +
&bypassAppCache</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font> </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 'auto-caching namespace'.</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> </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 'namespace-handler'... no
auto-caching involved.</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font> </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. 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 'namespace-handler' 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> </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> </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 <html
manifest='manifesturlforthisappcache'></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 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> </div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>Namespaces (name changes, refactored things a bit, and
introduced the 'intercept' 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 further lookup within the appcache
and resorts to the usual resource loading</span></font></div>* intercept -
doesn'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 serves a cached namespace-handler
resource</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>* fallback - hits server, does 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> </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> </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> </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> intercepting requests for urls</span></font><font color="#800000" size="2" face="Trebuchet MS"><span> 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'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> </div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>Something else we've wrestled with in Gears was having
to do awkward redesigns in corners of a web application in order to 'take it
offline', single-sign-on for example. In general, anywhere an application relies
on HTTP features more than HTML to influence navigation or conditional resource
loading, it'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> </div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>So I'd like to propose extending this spec to
incorporate 'dynamically generated responses'. I think this capability fits into
this corner of the HTML5 spec because this is most directly useful in the
"Offline Web Application" scenario. The basic idea is to execute application
code (script) to produce responses to intercepted resource loads. The
application code is executed in the background and can formulate a response
asynchronously.</span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font> </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 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> </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 'bypass' 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 to have the response added 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> </div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span>This would obviously be significant addition to the
spec, but i do think this is worth consideration in the context of 'offline
applications'. Based on observations of app developers wrestling with Gears,
there have been several pain points. The HTML5ApplicationCache addresses one of them with per-application caches. This addition would address
the second of them. (Another pain point has been application deployment).<br></span></font></div>
<div><font color="#800000" size="2" face="Trebuchet MS"><span></span></font> </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>