- From: Marcos Caceres <marcosc@opera.com>
- Date: Fri, 1 May 2009 18:06:36 +0200
- To: Scott Wilson <scott.bradley.wilson@gmail.com>
- Cc: Robin Berjon <robin@berjon.com>, public-webapps WG <public-webapps@w3.org>
On Fri, May 1, 2009 at 11:36 AM, Scott Wilson <scott.bradley.wilson@gmail.com> wrote: > 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: > Right. > - 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. > Right. > - 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. Right. The above is what I would expect as the appropriate behavior for widget instances. -- Marcos Caceres http://datadriven.com.au
Received on Friday, 1 May 2009 16:07:36 UTC