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

[whatwg] Comments/questions on 4.6 Offline Web applications

From: Adam Roben <aroben@apple.com>
Date: Fri, 12 Oct 2007 06:11:32 -0700
Message-ID: <470F7284.9090804@apple.com>
Ian Hickson wrote:
> On Sat, 6 Oct 2007, Adam Roben wrote:
>   
>> Here are some comments and questions about section 4.6 Offline Web 
>> applications:
>>     
>
> Thanks for the feedback! It was very useful in making the spec better. 
> Please do continue reviewing the spec!
>   

Glad to hear it!

>> Can javascript: URIs be specified in the manifest?
>>     
>
> I guess currently this is allowed...
>
> I'm not sure how to work around this. Blacklisting them is a bad idea, as 
> we'll forget some scheme that should be black-listed (e.g. vbscript:). 
> Should we just say that you can only cache files that have the same scheme 
> as the manifest? I've said that for now.
>   

That sounds reasonable to me.

>> It may be worth stating in this section what the behavior is when a 
>> section or opportunistic caching namespace appears multiple times. The 
>> parsing algorithm makes this clear, but it would be clearer still to 
>> also state the behavior in this section.
>>     
>
> Well, that would be non-conforming. I'm not sure we want to tell authors 
> what the error handling behaviour is when they ignore the conformance 
> requirements... do we?
>   

I see. I was not looking at this part of the spec from an application 
author's perspective. In light of that, I think the current level of 
detail is appropriate.

>> 4.6.4
>> -----
>> Steps 8.2 and 19.3.2 say that the user agent should "discard cache". What does
>> "discard cache" mean (in the case of an upgrade attempt, "cache" is a possibly
>> in-use cache)?
>>     
>
> The "discard cache" step is never reached when "cache" is in use. Is the 
> meaning really ambiguous? I'm not sure how else to say it.
>   

Somehow my eyes skipped over the phrase "If this is a cache attempt". In 
the case of a cache attempt, I think "discard" is perfectly clear.

>> Step 19 should specify what should happen if a URI that is already in the
>> cache's online whitelist is to be added as an explicit, fallback, or dynamic
>> entry.
>>     
>
> (Now step 20.) It does. Which is to say, it being on the online whitelist 
> has no effect. Should it have an effect? We can omit the caching of such 
> files if you want.
>   

Given that section 4.6.5.1 says that resources in the online whitelist 
are always fetched from the network, it seems that caching any resource 
that is in the online whitelist is simply a waste of time and space. I 
guess there's no need to explicitly state that such resources should not 
be cached -- implementors could design their implementation that way as 
an optimization.

-Adam
Received on Friday, 12 October 2007 06:11:32 UTC

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