[whatwg] HTML5 Offline Web Applications

[Michael Nordman]

Another one...

6) The DOMApplicationCache .length and .item(indx) members.

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?


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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081007/db147179/attachment-0001.htm>