[whatwg] HTML5 Offline Web Applications

[Maciej Stachowiak]

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  
> <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/67845c74/attachment.htm>