Re: Offline Web Applications status

On Thu, 31 Mar 2011, Michael Nordman wrote:
> 
> 1. Allow cross-origin HTTPS resources to be included in manifest files. 
> This much is actually done already in chromium impl as described on the 
> whatwg list.

I believe this is now done.


> 2. Allow a syntax to associate a page with an application cache, but 
> does not add that page to the cache. A common feature request also 
> mentioned on the whatwg list, but it's not getting any engagement from 
> other browser vendors or the spec writer (which is kind of frustrating). 
> The premise is to allow pages vended from a server to take advantage of 
> the resources in an application cache when loading subresources. A 
> perfectly reasonable request, <http useManifest='x'>.

I'll handle this as part of:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=14702

(My current plan is to do what I describe at the bottom of comment 27.)


> 3. Introduce a new manifest file section to INTERCEPT requests into a 
> prefix matched url namespace and satisfy them with a cached resource. 
> The resulting page would be free to interpret the location url and act 
> accordingly based on the path and query elements beyond the prefix 
> matched url string. This section would be similar to the FALLBACK 
> section in that prefix matching is involved, but different in that 
> instead of being used only in the case of a network/server error, the 
> cached INTERCEPT resource would be used immediately w/o first going to 
> the server. [...]
> 
> 4. Allow an INTERCEPT cached resources to be "executable". Instead of 
> simply returning the cached resource in response to the request, load it 
> into a background worker context (if not already loaded) and invoke a 
> function in that context to asynchronously compute response headers and 
> body based on the request headers (including cookie) and body. The 
> background worker would have access to various local storage facilities 
> (fileSystem, indexed/sqlDBs) as well as the ability to make network 
> requests via XHR. [...]
> 
> 5. Create a syntax to allow FALLBACK resources to be similarly 
> executable in a background worker context.
> 
> With the outline above in mind, this is why earlier in the thread i 
> questioned the need for an explicit add(url) and remove(url) sort of 
> api. That capability can be composed out of the file system and an 
> executable intercept handler. And there is also window.createObjectUrl() 
> and FileEntry.toUrl() which could cover many use cases that are behind 
> the feature request for add() and remove().

An idea I was kicking around for this would be to simplify the three 
points above to instead have just a way to declare a JS file as being a 
local interceptor, and then have that JS file be automatically launched in 
a worker thread, and then every network request gets proxied through that 
worker in some well-defined manner. The worker could then either say "do 
whatever you would normally do for that URL", or "redirect to this URL and 
try again", or "here's the data for that URL".

How does that sound?

Since this is essentially an alternative to the add/remove API proposal, 
I'm going to track it as part of this bug:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=14364

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

Received on Thursday, 3 May 2012 18:12:51 UTC