- From: Mike Wilson <mikewse@hotmail.com>
- Date: Mon, 3 Aug 2009 10:20:05 +0200
I agree it would be interesting to have the browser being able to distinguish between different variants of a page based on who is "logged in", whether it be through cookies or other mechanisms. But cookies should be included as they are one official way to store state. Storing several variants of a page in a cache, using some algorithm to select the suitable variant, draws many parallels with HTTP caching. A good way of working with AppCache features might be to first get them working with traditional caching. For traditional caching there is the HTTP 1.1 Vary header, that tells the browser what headers' values identify a unique page variant. F ex Vary: Cookie together with suitable Cache-Control headers would tell the browser to cache individual page variants for each value of the Cookie header. A problem with this is that it will treat all cookies for the page in one lump. In 1997 there was a proposal for identifying individual cookies, f ex: Vary: Cookie.USERID or Vary-Cookie: USERID but it seems it was dropped. Anyway, maybe it is interesting to reread the discussion to find correlations to current AppCache topics: http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997MayAug/0334.html As Ian says, client-centric webapps are probably the most straight-forward solution for offline apps. But given that the majority of today's webapps are probably server-centric, it would be interesting to see what can be done to easily support offline for them. It would be good to hear someone flesh out a (non-trivial) complete server-centric example, as there may be need for more features than just multi- variant pages to get it working well. Best regards Mike Wilson Ian Hickson wrote: > [...] > On Wed, 22 Jul 2009, Aaron Whyte wrote: > > > > Imagine two users of fancyapp.com, with their own logins > > and data and custom skins and whatnot. The contents of > > the main page are uncacheable and are totally different > > depending on the cookies in the request, which tell the > > server who is logged in. This is the way nearly every > > web app works today, and this is also the way a lot of > > people share a single computer. > > > > Without any offline support, they can share one browser, > > if one logs out of fancyapp, and the other logs in. > > > > If fancyapp supports offline use with Gears, then one of > > the users can install an offline client, without > > affecting the other user, because of requiredCookie. > > > > But if fancyapp supports offline use with HTML5's app > > cache, then if one user installs an offline client, > > fancyapp will keep working for that user, but not for > > the other user, who will have to go get their own > > computer, browser, profile, or whatever they need to > > avoid hitting the other user's app cache. > > > > The engineers at fancyapp could rewrite their mail page > > so it's just a little router that looks at cookies and > > makes subsequent requests to user-specific URLs to really > > load the app. But that's an inferior user experience, > > because it introduces an extra round trip to get the > > initial page properly rendered. So they'll probably have > > to support both. > > > > If the application code (HTML, JS, CSS) is all the same > > for two users, then appcache works for multiple users by > > just having the data for the users separate from the > > logic. [...]
Received on Monday, 3 August 2009 01:20:05 UTC