- From: poot <cvsmail@w3.org>
- Date: Wed, 29 Jul 2009 10:18:04 +0900 (JST)
- To: public-html-diffs@w3.org
hixie: Tweak microdata vcard example. Add appcache v2 idea for multiuser appcaches. (whatwg r3491) http://dev.w3.org/cvsweb/html5/spec/Overview.html?r1=1.2689&r2=1.2690&f=h http://html5.org/tools/web-apps-tracker?from=3490&to=3491 =================================================================== RCS file: /sources/public/html5/spec/Overview.html,v retrieving revision 1.2689 retrieving revision 1.2690 diff -u -d -r1.2689 -r1.2690 --- Overview.html 29 Jul 2009 00:32:06 -0000 1.2689 +++ Overview.html 29 Jul 2009 01:17:38 -0000 1.2690 @@ -38455,7 +38455,8 @@ <h2>Assorted Contact Methods</h2> <ul> <li itemprop="tel" item><span itemprop="value">+1 (310) 597 - 3781</span> <span itemprop="type">work</span></li> + 3781</span> <span itemprop="type">work</span> + <meta itemprop="type" content="pref"></li> <li><a itemprop="url" href="http://en.wikipedia.org/wiki/Jack_Bauer">I'm on Wikipedia</a> so you can leave a message on my user talk @@ -38466,7 +38467,7 @@ href="mailto:j.bauer@la.ctu.gov.invalid">j.bauer@la.ctu.gov.invalid</a></li> <li itemprop="tel" item><span itemprop="value">+1 (310) 555 3781</span> <span><meta itemprop="type" content="cell">mobile - phone</span>></li> + phone</span></li> </ul> <p itemprop="note">If I'm out in the field, you may be better off contacting <span itemprop="agent" item="vcard"><a @@ -44175,6 +44176,37 @@ http://groups.google.com/group/gears-users/browse_thread/thread/efbd808325df607a/c73adb34f9b63cf7?hl=en&q=whatwg#c73adb34f9b63cf7 + + * Multiuser appcaches. + + 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. + + This is the expected model for most apps. For example, your + typical blog has just one set of CSS for all users. + + For systems where the user affects what HTML, JS, and CSS is + served back, the spec as written pretty much requires that + there be one app per user, and one generic "login" app that + then redirects to one of those other apps - and where each app + has a different base URL, separate manifest, etc. + + An alternative that we could explore in a future version is to + have the manifest include a manifest name, and then have script + that allows you to "activate" a particular manifest name for a + given appcache. + + So each appcache group would be futher subdivided into named + subgroups, and for a given manifest URL with such a group of + subgroups, one subgroup would be the default one at a time. The + inactive ones would just lie dormant, but and the active ones + would act like now, but there'd be a scripted way to change the + default (and maybe query what available variants exist for the + current appcache), so that you could log back in as someone + else by just making the script pick the other user's variant, + and then reloading. + --><h4 id="introduction-4"><span class="secno">6.9.1 </span>Introduction</h4><p><i>This section is non-normative.</i><p>In order to enable users to continue interacting with Web applications and documents even when their network connection is unavailable — for instance, because they are traveling outside
Received on Wednesday, 29 July 2009 01:18:40 UTC