<div dir="ltr">Another one...<br><br>6) The DOMApplicationCache .length and .item(indx) members.<br><br>These two are troublesome in a multi-threaded / multi-process browser. Can we come up with an interface that's more ammenable to implementation non-single threaded browsers?<br>
<br><br><div class="gmail_quote">On Tue, Oct 7, 2008 at 2:03 PM, 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">Some more comments for the whatwg bit bucket...<br><br>1) Foreign entry detection<br><br>The spec points out an optimization when a foreign entry is discovered at cache-selection time, involving marking the entry as foreign at that time so  it will get filtered out of future searches during top-level navigation. Another optimization that could be pointed out is to detect foreign'ness upon insertion into the cache.<br>

<br>Really, it may be more clear if the spec were simply spec'd that way rather. The behavior exhibitted by the algorithms described corresponds with 'detect on insert', but accomplishes that in a less direct fashion.<br>

<br><br>2) Silent manifest parsing errors<br><br>The spec goes out of its way to indicate that most errors while parsing the manifest file should be silently eaten. That can't be an accident. What badness is being averted by that behavior? What is trying to be accomplished by that behavior?<br>

<br><br>3) Update algorithm<br><br>The intent is to grab a coherent set of resources that make up a 'version' of the app. No provisions are made to ensure that is what you actually end up with. Say the system starts an update, grabs the manifest file and starts fetching/validating resources. Half way thru, a new manifest file and set of resources lands on the server (or a new server is deployed). You end up with a mixed set of resources on the client.<br>

 <br><br>4) Why require text/cache-manifest mimetype?<br><br>Presents a small hurdle to get over. What is being accomplished with this requirement?<br><br><br>5) More thoughts on rephrasing the caching semantics of non-explicit entries<br>

<br>To job memories...<div class="Ih2E3d"><br>> One idea is to rephrase this feature in terms closer to std http caching for<br>
> all entries that do not explicily appear in the manifest file. In<br>
> effect, closer to telling the http cache to not purge the resource.<br><br></div>I was trading mail with somebody using Gears and this came up. The developer was interested in purging based on LRU when a threshold was exceeded. The app works with a unbounded (for all practical purposes) set of resources that could be cached.<br>

<br>If the 'contract' for these non-explicit entries required them be purged as quotas are bumped into, that would be ideal for this particular use case. These type of semantics could make a lot of sense for a class of apps like Flickr or PicassaWeg or YouTube.<br>

<br>So they don't expire according to normal http caching rules, and they are used as a fallback in the event of errors, but they are not guaranteed to be there forever unless you stay within a quota. <br></div>
</blockquote></div><br></div>