[e] (0) Tweak microdata vcard example. Add appcache v2 idea for multi…

…user appcaches. git-svn-id: http://svn.whatwg.org/webapps@3491 340c8d12-0b0e-0410-8428-c7bf67bfef74
whatwg · Jul 29, 2009 · df9e3a9 · df9e3a9
1 parent 030e9c4
commit df9e3a9
Show file tree

Hide file tree

Showing 2 changed files with 68 additions and 4 deletions.
diff --git a/index b/index
@@ -43064,7 +43064,8 @@ document.body.appendChild(outer);</pre>
  &lt;h2&gt;Assorted Contact Methods&lt;/h2&gt;
  &lt;ul&gt;
   &lt;li itemprop="tel" item&gt;&lt;span itemprop="value"&gt;+1 (310) 597
-  3781&lt;/span&gt; &lt;span itemprop="type"&gt;work&lt;/span&gt;&lt;/li&gt;
+  3781&lt;/span&gt; &lt;span itemprop="type"&gt;work&lt;/span&gt;
+  &lt;meta itemprop="type" content="pref"&gt;&lt;/li&gt;
   &lt;li&gt;&lt;a itemprop="url"
   href="http://en.wikipedia.org/wiki/Jack_Bauer"&gt;I'm on
   Wikipedia&lt;/a&gt; so you can leave a message on my user talk
@@ -43075,7 +43076,7 @@ document.body.appendChild(outer);</pre>
   href="mailto:j.bauer@la.ctu.gov.invalid"&gt;j.bauer@la.ctu.gov.invalid&lt;/a&gt;&lt;/li&gt;
   &lt;li itemprop="tel" item&gt;&lt;span itemprop="value"&gt;+1 (310) 555
   3781&lt;/span&gt; &lt;span&gt;&lt;meta itemprop="type" content="cell"&gt;mobile
-  phone&lt;/span&gt;&gt;&lt;/li&gt;
+  phone&lt;/span&gt;&lt;/li&gt;
  &lt;/ul&gt;
  &lt;p itemprop="note"&gt;If I'm out in the field, you may be better
  off contacting &lt;span itemprop="agent" item="vcard"&gt;&lt;a
@@ -49145,6 +49146,37 @@ interface <dfn id=function>Function</dfn> {
 
        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>

diff --git a/source b/source
@@ -48614,7 +48614,8 @@ document.body.appendChild(outer);</pre>
  &lt;h2>Assorted Contact Methods&lt;/h2>
  &lt;ul>
   &lt;li itemprop="tel" item>&lt;span itemprop="value">+1 (310) 597
-  3781&lt;/span> &lt;span itemprop="type">work&lt;/span>&lt;/li>
+  3781&lt;/span> &lt;span itemprop="type">work&lt;/span>
+  &lt;meta itemprop="type" content="pref">&lt;/li>
   &lt;li>&lt;a itemprop="url"
   href="http://en.wikipedia.org/wiki/Jack_Bauer">I'm on
   Wikipedia&lt;/a> so you can leave a message on my user talk
@@ -48625,7 +48626,7 @@ document.body.appendChild(outer);</pre>
   href="mailto:j.bauer@la.ctu.gov.invalid">j.bauer@la.ctu.gov.invalid&lt;/a>&lt;/li>
   &lt;li itemprop="tel" item>&lt;span itemprop="value">+1 (310) 555
   3781&lt;/span> &lt;span>&lt;meta itemprop="type" content="cell">mobile
-  phone&lt;/span>>&lt;/li>
+  phone&lt;/span>&lt;/li>
  &lt;/ul>
  &lt;p itemprop="note">If I'm out in the field, you may be better
  off contacting &lt;span itemprop="agent" item="vcard">&lt;a
@@ -55922,6 +55923,37 @@ interface <dfn>Function</dfn> {
 
        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>Introduction</h4>