[whatwg] The Offline Application Cache system feedback

[Ian Hickson]

On Wed, 19 Mar 2008, Anders Carlsson wrote:
>
> The text:
> 
> A browsing context can be associated with an application cache. A child 
> browsing context is always associated with the same browsing context as 
> its parent browsing context, if any.
> 
> should be:
> 
> A browsing context can be associated with an application cache. A child 
> browsing context is always associated with the same *application cache* 
> as its parent browsing context, if any.

Oops. Fixed.


On Thu, 20 Mar 2008, Anders Carlsson wrote:
>
> "If there is already an application cache identified by this manifest 
> URI, and that application cache contains a resource with the URI of the 
> manifest, and that resource is categorised as a manifest, then: store 
> the resource in the matching cache with the most up to date version, 
> categorised as an implicit entry, associate the Document with that 
> cache, invoke the application cache update process, and abort these 
> steps."
> 
> as well as
> 
> "If there is already an application cache identified by this manifest 
> URI, then that application cache does not yet contain a resource with 
> the URI of the manifest, or it does but that resource is not yet 
> categorised as a manifest: store the resource in that cache, categorised 
> as an implicit entry (replacing the file's previous contents if it was 
> already in the cache, but not removing any other categories it might 
> have), and abort these steps."
> 
> need to clarify that the cache needs to be the most recently updated 
> cache in the group.

Fixed.


On Fri, 21 Mar 2008, Anders Carlsson wrote:
>
> Resources that were listed in the cache's manifest. Explicit entries can 
> also be marked as foreign, which means that they have an manifest 
> attribute but that it doesn't point at this cache's manifest.
> 
> an manifest => a manifest

Fixed.


On Fri, 21 Mar 2008, Alexey Proskuryakov wrote:
> 
> > The user agent must decode the bytestream corresponding with the 
> > manifest to be parsed, treating it as UTF-8. Bytes or sequences of 
> > bytes that are not valid UTF-8 sequences must be interpreted as a 
> > U+FFFD REPLACEMENT CHARACTER. All U+0000 NULL characters must be 
> > replaced by U+FFFD REPLACEMENT CHARACTERs
> 
>   The requirement to replace NULL characters with U+FFFD appears to be 
> non-verifiable, as the effect of preserving NULLs is the same (an URL is 
> treated as invalid).
> 
>   I think it would be better to omit this requirement, as it is just a 
> disguised and somewhat misguiding warning about the perils of NULLs in 
> strings (usually in C-style strings). At least for WebKit, I expect that 
> it would be safer and easier to avoid such problems without introducing 
> a new decoder mode just for manifests.

Commented it out.


On Fri, 4 Apr 2008, Anders Carlsson wrote:
>
> From section 4.6.6:
> 
> The item(index) method must return the dynamic entries with index index 
> from the application cache, if one is associated with 
> theApplicationCache object.
> 
> "entries" should be "entry".

Fixed.


> Also, it should be clarified that the item returns the uri of the entry.

Fixed.


On Tue, 8 Apr 2008, Anders Carlsson wrote:
>
> The spec for the add and remove ApplicationCache methods does not say 
> what to do about how relative URIs should be resolved.
> 
> I think it would be most intuitive to resolve them agains't the URI o 
> the document that the ApplicationCache object is associated with.

I've added an issue marker in the spec to deal with this. I want to deal 
with all the places that resolve relative URLs at the same time.


On Tue, 8 Apr 2008, Jeff Walden wrote:
> 
> Generally I believe URIs have been resolved against the URI of the 
> document that the script that invoked the method is associated with.  
> For example, if I have origin A and pages A_1 and A_2, a script on A_1 
> that uses, say, A_2.XMLHttpRequest.open with a relative URI will have 
> that URI resolved against A_1.location.href.  Similar precedent applies 
> to loading scripts or iframes, calculating the sender's URI for events 
> dispatched by postMessage, and other such uses.  Think of it this way: a 
> relative URI used from script is "lexically" scoped to the document that 
> loaded the script, and any relative URIs used have the same semantics 
> any time that code executes -- they're not dependent on the location of 
> the document associated with the ApplicationCache, which might or might 
> not be what you actually expected it to be at runtime.
> 
> What you suggest goes against a lot of precedent, from my point of view.  
> If only for consistency, I think we're better off making relative URIs 
> be lexically scoped such that they're resolved against the location of 
> the document in which the script is executed.

Yeah, I want everything consistent here.


On Thu, 17 Apr 2008, Anders Carlsson wrote:
> 
> I think an exception should be thrown when ApplicationCache add/remove 
> is called with invalid URLs. Something like
> 
> "If uri is not valid, raise an SYNTAX_ERR exception and abort these 
> steps."

Added for add(); for remove() I'd rather just silently fail since that's 
what we do if the URI isn't there. Otherwise authors might get caught 
between UA bugs where they can add something they can't remove, etc, 
depending on what's going on. It's always annoying when you can see 
something but can't remove it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'