Re: Widget instances and widget invocations

On Thu, Apr 30, 2009 at 4:45 PM, Robin Berjon <robin@berjon.com> wrote:
> 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

Don't like this.

>  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

C seems to be what Dashboard does. It seems to clone the preferences
of the last widget type that was opened. E.g., I open a clock, I set
it preference "Brisbane", I open another clock and it starts as
Brisbane. I close both, and open a new clock and I get "Brisbane"
(everything without gaining any weight from eating ice-cream, btw!).

> 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.
>

Agreed.
-- 
Marcos Caceres
http://datadriven.com.au

Received on Friday, 1 May 2009 16:01:56 UTC