On Oct 7, 2008, at 4:49 PM, Michael Nordman wrote:
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?
Don't you need to have some particular version of the application
cache loaded in the thread or process that is processing the
particular web page using these APIs? It seems to me that the
application cache's atomic update semantics effectively require that,
since loading needs to keep a consistent view of the application cache
regardless of changes caused by other pages, so length and item are
not an obstacle.
Regards,
Maciej
On Tue, Oct 7, 2008 at 2:03 PM, Michael Nordman
<[EMAIL PROTECTED]> 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.
