Shared publicly  - 
 
I made a proposal for a new, dramatically revamped, AppCache.

In order to not repeat the mistakes of the past I'd really like to get feedback from web developers in order to make it work well with how websites are actually developed and deployed.

So not just looking to create something that lets us improve performance slightly, but something that actually dramatically changes online performance as well as make offline apps possible.

I.e. something that's actually pleasant to develop using.

So please provide feedback here, on the webapps mailing list, or by emailing me directly.
W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013. Fixing appcache: a proposal to get us started. This message : [ Message body ] [ Respond ] [ More options...
13
14
Mathew Ballard's profile photogeorge oloo's profile photoEugene Krevenets's profile photoJulian Viereck's profile photo
12 comments
 
+1 for JSON

Improvements:

* sooner or later, these manifests will, in part or whole, want to be js reachable, so:

* make all manifest properties js-legal lowercase identifiers — last-modified -> last_modified, et c, so we'll be able to use readable dot notation to reference them

* for all things timestampy, always accept timezone-neutral unix-time integers too — shorter, easier, and better interoperable
 
Both great points! Will update the proposal.
 
Tooling to work with this in the browser is vital as well – an easy way to see what's going on, and to be able to invalidate entries via the dev tools will make this great – IMO this should be included as part of the initial implementation.
 
The biggest gotcha for me was developing a site while having a manifest I wouldn't get the updated resources. JS call to flush resources cached by current manifest would be nice. Event listening on caching might also be useful.

+1 tooling
 
I was an attendee at Edge Conf and there was a great session on tackling offline browsing:
Edge Conference - Panel 1: Offline

The problem with current appcache is that it tries to do two things at once: Routing and Caching.

Really, appcache should be cleanly split in two, the app should handle routing!

Having a dedicated request router API alongside the caching API is the best of both worlds.

You can then get rock solid caching as well as flexibility of handling routing requests -- something that usually has to be hacked on by the framework instead of being able to rely on a good API.

Caching API can be something simple then, a key-value/key-file store alongside useful metadata. Maybe optionally offer API calls to the browsers' caching algorithm?



Just finished reading your email on the mailing list, and yeah, it seems your starting to sensing the problem of appcache trying to do two things at once.

The router being a worker or not is bit of a contentious issue.
Pro:
- Multi-threading is good
Cons:
- Web workers can do little: http://stackoverflow.com/questions/6179159/accessing-localstorage-from-a-webworker

On the other hand you could more easily cater to specific API that works only in this web worker context. I could imagine a routing request for "account/joe-schmoe/avatar.png", you could go to the caching API of a key-file store and tell the shared-worker-like request to answer with avatar image file data related to that user.
 
Yeah, that edge conf session was pretty good - wasn't there but watched the videos. Was that proposal a serious one or just an early discussion?
 
+Rich Bradshaw Totally agree on tooling. I'm planning on working together with the devtools team in order to ensure that support there happens in parallel with the implementation.

And yes, the proposal at Edge was a serious one. It's called the NavigationController. My intent is that NavigationController and AppCache should be aligned to work really well together. But you should also be able to use just NavigationController if your use cases are complex enough that the AppCache doesn't really buy you anything, or use just AppCache if your website is simple enough that it meets your needs.

+Henrik Vendelbo The new proposal should handle that. By default it checks for updates on all files even if the manifest hasn't changed. There's also JS functions for forcing an update check as well as downloading an update.
 
+Nexii Malthus First off, you should check out the NavigationController proposal which is what was presented at Edge.

Second, the new AppCache proposal does contain both routing and caching. I think without routing support it would end up not supporting enough website. Almost any website which exposes a database will end up with an unbounded URL space that you'd want to catch.

But what the new AppCache proposal does do is that it separates the caching and the routing as two clearly distinct features, which should hopefully help.

I agree that using a worker for the NavigationController is problematic. However I think you unfortunately need it in a worker in order to avoid deadlocks. I.e. you could otherwise too easily end up with a page being blocked on a certain resource being loaded, meanwhile the resource won't be loaded until the same (blocked) has decided how to route the network request.
 
+Jonas Sicking Exciting times – will be nice to have the tools to make offline apps that work as we want :)
 
I love the idea of putting etag's for each cached resource in the manifest.   This would allow an app framework to declare a content-based etag (hash) for each cached resource - and declare that the client need not update any resource if it already has the etag-identified version in the latest manifest (which is in-turn cached by etag).

I can see benefits to allowing additional collections of files into the cache would also be useful for apps that have more extended functionality and want different levels of caching for extended features.

We need a way for users to allow app caches to be much larger as well.

As for programmatic access - given JS support for reading and modifying resource in the cache would eliminate the need to hack data urls when using other offline storage as a cache.
 
Regarding comments in JSON. 

Couldn't you spec it so that browsers must handle comments in their implementation, but are allowed to warn that servers may not be able to handle it.

I'm not convinced though that it is a problem as coding policies on the serverside can ensure comments aren't used. Eventually servers would migrate to comment supporting parsers, so it would only be a transition period.
 
Love that "victim of its own success"
Add a comment...