Re: [widgets] dropping Asynchronous HTTP Requests and Storage

On 7 Apr 2009, at 11:51, Robin Berjon wrote:
> There are two ends to this spectrum: one is developing a toolbox  
> technology that can just fit with other technologies, the other is  
> defining a platform that developers can author content for in a  
> reliable manner.
>
> I don't have a strong opinion on the outcome, but I don't think that  
> we should base our decision solely on where some of us think we  
> should place the specification on that spectrum — if only because  
> such discussions tend to be based mostly on personal preference and  
> anecdotal evidence. I think it should stand or fall on the  
> requirement's merit, and on what we expect the typical usage to be  
> (as opposed to contrived examples). I think that having preferences  
> is a required feature for a widget, and I think that the typical  
> cases (HTML/SVG content) will support Storage anyway, so there's no  
> harm — and in fact extra convenience — in using it for the  
> preferences attribute.

I agree; preferences is a core feature of Widgets, and having  
Widget.preferences use the Storage *interface definition* -  
irrespective of what is used to implement it - gives a stable  API for  
developers authoring widgets.

At the same time it also does not rule out any UA implementations,  
which a reliance on the LocalStorage *implementation* of Web Storage  
would.

For HTML5-compliant UAs, the added burden of writing:

Widget.preferences = localStorage

... seems hardly worth serious objection.

For non-HTML5 UAs, e.g. Flash-based, there is no real difference in  
effort between implementing the getPref/setPref method signatures and  
the Storage method signatures.

S