Re: Fixing appcache: a proposal to get us started

On Mon, Apr 1, 2013 at 4:03 AM, Glenn Jones
<glennjonesnet@googlemail.com> wrote:
> 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.

I like this a lot! I definitely want to make sure that we don't end up
with full regexp complexity in the type of patterns that we support,
but I agree that only supporting prefixes does seem like too small of
a subset.

I wouldn't be surprised if we'll end up having to expand to support
things like query parameters as well, but starting with prefixes and
patterns that can do wild-cards for individual path segments sounds
great.

/ Jonas

Received on Wednesday, 1 May 2013 04:12:46 UTC