W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Widget instances and widget invocations

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Fri, 1 May 2009 10:36:49 +0100
Cc: public-webapps WG <public-webapps@w3.org>
Message-Id: <EFCAF944-D47A-4010-8AF1-F094DA82DB63@gmail.com>
To: Robin Berjon <robin@berjon.com>
Hi Robin,

I think you're missing a scenario, which is where your multiple  
instances are for different users. In which case "A" is the only  
viable option. "C" would mean that User A gets User B's preferences  
for their widget.

I imagine for most if not every UA that invoking a widget involves  
instantiating a containing object  which has a persistent local  
identifier, so the issue you raise on the "A" option is a non-issue  
for existing UAs.

Note that the issue largely arises because of this "Kill widget"  
behaviour which is not one which is defined in the specification:

- If you try this out now in Apple Dashboard, for example, you'll find  
that "Kill Widget" (i.e. remove from dashboard) also deletes all  
information associated with the instance, so the issue would not arise.

- In our implementation (Wookie), if you delete an instance from the  
page (i.e. remove a widget block from a user profile page in a social  
app), then add another instance of the same widget, the original  
preferences have been removed in the same manner as in the Apple  
Dashboard example, as each widget block is a unique context as far as  
the web application and Wookie are concerned. However, if you just  
close down the browser window, and then reopen the same page in a new  
browser window, then the server supplies the persisted instance ids on  
re-rendering the page, so instances retain the same preferences keyed  
on their original context.

S

On 30 Apr 2009, at 15:45, Robin Berjon 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
> 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 Friday, 1 May 2009 09:37:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT