- 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