Re: Fixing appcache: a proposal to get us started

I think this outline for improving AppCache is a really good start, but I
can see one major problem with it. As you point out AppCache was initially
designed for building simple single page web apps.

> The appcache appears to be aimed at too simple applications. It works
> fine if the website you want to cache consists of a small set of
> static resources and otherwise only use features like IndexedDB or
> localStorage to manage dynamic data. But once an application uses
> server-side processing to dynamically generate resources based on
> query parameters or other parts of the URL, then it requires that you
> change the way that your application works.

I completely agree with the above point, but I don’t think it can be done
with prefix URLs, which are all but useless in dealing with “dynamically
generated resource based” sites. The example code you give for urlmaps only
shows how prefixs can be used to handle querystrings.

What is required is a way to cover all the common URL design patterns found
in the real world i.e. paving cow paths.  Most importantly we need url
matching that works against section namespace design patterns i.e.

https://github.com/glennjones/microformat-node/issues
http://lanyrd.com/2012/jsconf-us/speakers/
http://www.quora.com/URLs/recent

To deal with theses URL structures you need to use something like the route
matching built into JavaScript MVC frameworks

"urlmap": [{
      url: "https://github/:*/:*/issues",
      page: "https://github/profile/project/issues"
}]

In the example above the :* wildcards match against the section of the URL
which needs to be ignored and allows you to match at a deeper level than
prefix urls.

Unless the new version of AppCache supports the current patterns of URL
design used on the web it will be forever assigned to build single page
apps.  There will be no chance of progressively enhancing a large complex
site with AppCache, if it cannot deal with pre-existing URL design.