- From: Michael Nordman <michaeln@google.com>
- Date: Wed, 8 Oct 2008 11:27:30 -0700
On Tue, Oct 7, 2008 at 10:28 PM, Maciej Stachowiak <mjs at apple.com> wrote: > Dont you need to have some particular version loaded in the thread I think you're focusing on a particular implementation. Suppose that version is shared by all pages using these APIs. > atomic update The set of cached resources is mutable. This API provides access to the mutable parts of the collection. Don't see how updating the collection as a whole is related? Here's the thing i'm trying to avoid in section 5.7.6 where it discusses the add(url) method. ... 8. "Wait for there to be no running scripts, or at least no running scripts that can reach an ApplicationCache object associated with the application cache with which this ApplicationCache object is associated." ... The same system-wide synchronization has to be applied for the remove(url) method. The utility of the .length and .item(indx) method could be provided in such a way that this awkwardness could be avoided. Some ideas... bool contains(url); string[] getItems(); > > Regards, > Maciej > > > > > On Tue, Oct 7, 2008 at 2:03 PM, Michael Nordman <michaeln at google.com> wrote: >> >> Some more comments for the whatwg bit bucket... >> >> 1) Foreign entry detection >> >> 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. >> >> 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. >> >> >> 2) Silent manifest parsing errors >> >> 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? >> >> >> 3) Update algorithm >> >> 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. >> >> >> 4) Why require text/cache-manifest mimetype? >> >> Presents a small hurdle to get over. What is being accomplished with this requirement? >> >> >> 5) More thoughts on rephrasing the caching semantics of non-explicit entries >> >> To job memories... >> > 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. >> >> 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. >> >> 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. >> >> 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. > >
Received on Wednesday, 8 October 2008 11:27:30 UTC