- From: Robin Berjon <robin@berjon.com>
- Date: Thu, 30 Apr 2009 16:45:59 +0200
- To: public-webapps WG <public-webapps@w3.org>
Hi, here's my quick stab at a definition: - multiple instances of a widget are the same widget (one installation) being run multiple times in parallel, e.g. a weather widget that you run once for the weather in Paris and once for the weather in Sydney; - multiple invocations of a widget are the same widget being run multiple times serially in time, which is to say that the n+1 invocation happens after invocation n has been stopped. The above part is for the definitions, what follows is discussion of some implications. Now consider this: - I invoke a widget once - I change some preferences or effect storage somehow - I kill it - I go eat some ice-cream - I come back, and invoke the same widget again In this case, I want the second invocation to have access to the same storage — otherwise my work is lost. Now here's with multiple instances: - I invoke a widget once - I change some preferences or effect storage somehow - I invoke the same widget a second time, getting a second instance - I kill widget 1 - I change some preferences or effect storage somehow in widget 2 - I kill widget 2 - I go eat more ice-cream - I come back, and invoke the widget again What information do I get back if I look inside the storage? There are multiple options: a) the UA has somehow allowed me to pick which instance I run, I get back what I put for the right instance b) the UA has become confused, I get both values, or something broken, or nothing c) the UA has a single origin mapped to my widget, I get the last write The ideal option here may be (a) but I'm unsure that it's realistic. Basically it would mean that the UA would have a mechanism to run an extra instance and to allow me to identify it (e.g. run widget as new profile). Would a newly created instance inherit the storage from one of the previous ones or a clean slate? This is getting uncomfortably close to a UI spec for me. I think we agree we don't want (b). I'm going to propose that we go with (c) — this is just like multiple tabs open to the same page. If a UA wants to offer a way to make a given instance separate (i.e. provide it with a different origin) that is of course fine, but IMHO it is the same problem as allowing a user to have different cookies in different tabs in a browser: useful, but not defined per spec. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Received on Thursday, 30 April 2009 14:46:36 UTC