<br><br><div class="gmail_quote">On Mon, Nov 17, 2008 at 8:05 PM, Ian Hickson <span dir="ltr"><ian@hixie.ch></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Based on this and other offline feedback (no pun intended), I've changed<br>
the spec to make <iframe>s never inherit the manifest.</blockquote><div><br></div><div>Seems workable... of course until app developers actually start trying to use this system, the real world implications of these sort of design decisions will remain TBD.</div>
<div>  </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">> >> * intercept namespaces [new]<br>> ><br>
> > This isn't supported; the network is always consulted. But if the<br>
> > network request fails, then a fallback resource is used, though it<br>
> > cannot be generated on the fly.<br>
><br>
> Why? I had assumed this was a simple omission in the original draft. Can<br>
> you explain the rationale behind not having this feature? What am i<br>
> missing?<br>
<br>
The rationale for not having any feature is the same -- there was either<br>
not enough rationale for adding it, or the rationale didn't outweigh the<br>
cost of adding it at this stage. This is something we can delay until a<br>
later version. It's more important to get interoperable behavior sooner<br>
than to get a complete API later.<br>
<br></blockquote><div><br></div><div>Fwi, this piece of functionality may warrant some actual consideration.  I think this would add very little complexity to the spec and implementations, but would add a great deal of value. Big bang for little buck. </div>
<div><br></div><div>Many applications that use Gears depend on the intercept ability in some central fashion. Lets just take an example from Google Docs use of Gears. There are two intercept entries for urls of the form /Doc? and /View?. Doc provides an editable interface. View provides a read-only view. The document id is provided to these pages as a query parameter. Upon loading, these cached pages examine the query params and retrieve the appropiate document data from the an SQL database, and populate the DOM accordingly. This is a fairly common use case from what I've seen.</div>
<div><br></div><div>I think the inclusion of a feature along these lines would greatly help existing Gears users migrate to this new system.</div><div><br></div><div><br></div></div>