W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2008

[whatwg] HTML5 Offline Web Applications

From: Michael Nordman <michaeln@google.com>
Date: Tue, 7 Oct 2008 14:03:10 -0700
Message-ID: <fa2eab050810071403q29cb47cbuf68ad54da9c9ab06@mail.gmail.com>
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/790ebdee/attachment.htm>
Received on Tuesday, 7 October 2008 14:03:10 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:06 UTC