[whatwg] AppCache can't serve different contents for different users at the same URL

[Adam de Boor]

the difficulty with a named-section option is that the manifest generation
for an application would have to know which users use a particular machine,
which is pretty much a non-starter.
a

On Tue, Jul 28, 2009 at 6:08 PM, Ian Hickson <ian at hixie.ch> wrote:

> 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.
>
> I think conceptually that's actually not a bad idea anyway, to be honest.
> However, I could see that it might not be the preferred model.
>
> 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.
>
> I've noted this in the spec as a possible v2 feature.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090728/c2faaf3a/attachment-0002.htm>