W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2009

[whatwg] Application cache updating synchronicity

From: Michael Nordman <michaeln@google.com>
Date: Fri, 4 Dec 2009 14:24:53 -0800
Message-ID: <fa2eab050912041424i3d809c80y74931a74c604f633@mail.gmail.com>
My interpretation of this is that "atomically" is not to be read as
"synchronously" with regard to <html> tag parsing
(which ultimately initiates the update algorithm). Otherwise step 1 could
leave a blank page on the screen indefinitely (which is not the intent
afaict).

A clarification in the spec would help.

Even in the absence of async user-interactions alluded to by step 1,
allowing for async'ness at this point is beneficial since initial page
loading can make progress w/o having to consult the appcache prior to
getting past the <html> tag.

On Fri, Dec 4, 2009 at 2:01 PM, Alexey Proskuryakov <ap at webkit.org> wrote:

> Recently, a new step was prepended to the application cache update
> algorithm:
>
> "1. Optionally, wait until the permission to start the application cache
> download process has been obtained from the user and until the user agent is
> confident that the network is available. This could include doing nothing
> until the user explicitly opts-in to caching the site, or could involve
> prompting the user for permission. The algorithm might never get past this
> point. (This step is particularly intended to be used by user agents running
> on severely space-constrained devices or in highly privacy-sensitive
> environments)."
>
> It's not clear if it's supposed to synchronous or not. The "doing nothing"
> clause suggests that page loading can continue normally. On the other hand,
> the algorithm says that asynchronous processing only begins after step 2,
> which runs "atomically".
>
> - WBR, Alexey Proskuryakov
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091204/0574871e/attachment.htm>
Received on Friday, 4 December 2009 14:24:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:54 UTC