[whatwg] Application cache updating synchronicity

Michael Nordman michaeln at google.com
Fri Dec 4 14:24:53 PST 2009


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-0002.htm>


More information about the whatwg mailing list