<br><br><div class="gmail_quote">On Fri, Oct 17, 2008 at 5:36 PM, Ian Hickson <span dir="ltr"><ian@hixie.ch></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br>
<br>
> - I know you added the behavior of failing loads when a URL is not in<br>
> the manifest based on something I said, but now that I read it, it feels<br>
> a bit draconian. I wish that developers could somehow easily control the<br>
> space of URLs they expect to be online as well as the ones they expect<br>
> to be offline. But maybe we should just remove the whole thing about<br>
> failing loads of resources not in the manifest and online whitelist for<br>
> v1.<br>
<br>
It seems like failing is what one wants from a debugging perspective.<br>



<br>
> Not sure the "fail if not represented in manifest" is a good idea<br>
> either... are there unintended consequences lurking here... what does<br>
> this do in the face of mashups?<br>
<br>
I'm not sure I understand; can you elaborate?<br></blockquote><div><br></div><div>I was referring to the fail to load behavior discussed above. The change such that iframes do not inherit their container's appcache alleviates my concerns.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Hmm, good point. Renamed them "master entries".</blockquote><div><br></div><div>Works for me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

> * flavors of namespaces*<br>
><br>
>  * online whitelist<br>
> As mentioned in previous messages, this would need to be some form of<br>
> namespacing or filtering to be useful. A better term for this might be<br>
> 'bypass' since with respect to the appcache, hits here bypass the cache. Its<br>
> not clear if path prefix matching is the best option for filtering out<br>
> request that should bypass the cache. In working with app developers using<br>
> Gears, the idea of specifying a particular query argument to filter on in<br>
> addition to a path prefix has come up. <a href="http://server/pathprefix" target="_blank">http://server/pathprefix</a>   +<br>
> &bypassAppCache<br>
<br>
I've changed it to just a prefix. Doing things at the query level seems a<br>
bit odd. The query parameters should be for the server, not the UA.</blockquote><div><br></div><div>Agreed that query params should be for the application logic, where ever the application logic resides:)</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> * opportunistic caching namespaces<br>
> A mouthful but ok. Whatever terminology used for the category of resulting<br>
> entries should be used here... perhaps 'auto-caching namespace'.<br>
<br>
This is gone now.<br></blockquote><div><br></div><div>Hooray</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> *Scriptlets - or dynamic namespace-handlers [new idea]*<br>
I haven't added this in this version.</blockquote><div><br></div><div>I'm content that this idea has been injected into the collective consciousness and am reasonably confident that sooner or later its time will come :)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">> *When is anything ever deleted?*<br>
><br>
> Maybe i missed it, but where does appCache deletion happen?<br>
<br>
It didn't. It now does, in response to 404 or 410 statuses for manifests<br>
when doing an update.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
> A new type of event may be warranted for completion of such an update,<br>
> and when swapCache() is called there would no longer an appCache<br>
> associated with the context.<br>
<br>
Done.<br></blockquote><div><br></div><div>Good</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> *Should we revisit the caching semantics for any resource not explicitly<br>
> listed in the manifest?<br><br>
I'm not a big fan of making these resources act differently than manifest<br>
resources, but I do agree that they should have different error handling.<br>
<br>
I've changed the spec so that 404 and 410 errors cause the resource to be<br>
removed, and other errors (and redirects) cause the resource to be copied<br>
from the previous cache, without the whole caching process being canceled.<br>
<br></blockquote><div><br></div><div>Content that the bug is fixed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> b) Maybe there should be some way for the page to know that it was<br>
> loaded as a fallback.<br>
<br>
I could add something to Location, would that work?<br>
<br>
   window.location.fallbackHref<br>
<br>
...or something? It would return the empty string unless it was a fallback<br>
case?</blockquote><div><br></div><div>Not sure anything is needed here. If an app really needs to know this, it could arrange such that a fallback resource should only be loaded in the fallback case for normal application usage.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> 2) Silent manifest parsing errors<br>
><br>
> The spec goes out of its way to indicate that most errors while parsing the<br>
> manifest file should be silently eaten. That can't be an accident. What<br>
> badness is being averted by that behavior? What is trying to be accomplished<br>
> by that behavior?<br>
<br>
We want a format that is forward-compatible and convenient to use.<br>
<br>
I'm open to other syntaxes; what would you suggest?<br></blockquote><div><br></div><div>This was not a comment about the file format, rather how errors in the file are surfaced to the application.  We've seen with gears, that its easy to introduce errors in the file (malformed urls or same-origin violations). Wasn't thinking about forward-compatibility. The 'fail if not in cache' semantics may help.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">> 4) Why require text/cache-manifest mimetype?<br>
><br>
> Presents a small hurdle to get over. What is being accomplished with<br>
> this requirement?<br>
<br>
This is actually just a restatement of HTTP's requirements. If you want<br>
the Content-Type to be ignored, please contact the HTTP working group and<br>
have them change the requirements for handling HTTP Content-Type headers. :-)<br></blockquote><div><br></div><div>Could we specify text/plain (or text/*) as the valid content type so a developer doesn't need access to the server infrastructure to get UAs to accept her/his text resource as a manifest file?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I've added an allowance for expiring resources. It's pretty open-ended,<br>
left up to the UA.<br></blockquote><div><br></div><div> Great</div><div><br></div><div>--------------------------------------------------------------------------</div><div>New topics</div><div><br></div><div>* Its not clear that resources add()ed around update initiation time will make their way to a new cache that results from the update. I think the intent is that add()ed resources will show up in the new cache regardless of when add() is initiated or completed, but this isn't clear.</div>
<div><br></div><div>* Is it an error to initiate the add() of a resource to a cache after it has become obsolete?</div><div><br></div><div>* Should there be onaddsuccess / onadderror  events that fires when add(s) complete?</div>
<div><br></div><div>* Pseudo code omission (i think):  I don't see where the pseudo code inserts new master entries or informs already running update of newly discovered master entry.</div><div><br></div><div>* Towards the end of an update, 'candidates' are not associated with the new cache in the upgrade attempt case. The differences between the cache attempt vs upgrade attempt seems odd.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">
</font></blockquote></div><br>