Re: [widgets] dropping Asynchronous HTTP Requests and Storage

[Arthur Barstow]

On Apr 6, 2009, at 6:46 AM, ext Marcos Caceres wrote:


I had a discussion with Anne on IRC about using the Storage interface
and XHR [1]. He recommended that we recommend support for Storage only
on user agents that support HTML5. With regards to XHR, the same
applies: it would be a property of the underlying document technology.

So, proposal are: drop "Asynchronous HTTP Requests" requirement [2]  
and
remove its support from Widgets 1.0: A&E. For Storage, specify that  
only

HTML-aware UAs support Storage interface.


Regarding the Storage proposal, we've debated this before. I support  
the existing text and its adoption/reuse of HTML5's Storage interface.


As Jonas indicated, the Storage interface has been moved from HTML5  
to a separate Web Storage spec [1] that WebApps will publish soon  
(perhaps as early as next week).


-Regards, Art Barstow

[1] 

Re: [widgets] dropping Asynchronous HTTP Requests and Storage

[Scott Wilson]

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

smime.p7s
Description: S/MIME cryptographic signature

Re: [widgets] dropping Asynchronous HTTP Requests and Storage

[Robin Berjon]

On Apr 7, 2009, at 12:25 , Marcos Caceres wrote:
On Tue, Apr 7, 2009 at 11:10 AM, Robin Berjon   
wrote:
Well, my understanding was that we had to have Web Storage for API  
& Events
anyway since that's what implements preferences (and we need to  
define how
it's used so that we can get read-only keys). Even if that's all  
there is,

it'd be a little bit silly for a UA to support Web Storage for the
preferences but not in other contexts.


True. However, Anne seems to be implying that we should not replicate
functionality available in other context. For example, would a
(hypothetical) Flash-only Widget UA be expected to implement Storage?
Or would we mandate that such user agents implement their own solution
or use whatever means are currently available on the platform
(whatever that might be for Flash)?


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.


--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/

Re: [widgets] dropping Asynchronous HTTP Requests and Storage

[Marcos Caceres]

On Tue, Apr 7, 2009 at 11:10 AM, Robin Berjon  wrote:
> On Apr 7, 2009, at 06:37 , Jonas Sicking wrote:
>>
>> On Mon, Apr 6, 2009 at 8:48 AM, Scott Wilson
>>  wrote:
>>>
>>> On 6 Apr 2009, at 15:33, Anne van Kesteren wrote:
>>>
 You will have this problem regardless of how you solve this issue if you
 do not also require a specific scripting language, markup language, etc.
>>>
>>>
>>> It seems to be rather strongly _implied_ that widgets will use HTML,
>>> ECMAScript and CSS...
>>
>> Could we also similarly imply that the .localStorage API also be
>> implemented? This is especially easy now that localStorage is becoming
>> its own spec [1].
>
> Well, my understanding was that we had to have Web Storage for API & Events
> anyway since that's what implements preferences (and we need to define how
> it's used so that we can get read-only keys). Even if that's all there is,
> it'd be a little bit silly for a UA to support Web Storage for the
> preferences but not in other contexts.

True. However, Anne seems to be implying that we should not replicate
functionality available in other context. For example, would a
(hypothetical) Flash-only Widget UA be expected to implement Storage?
Or would we mandate that such user agents implement their own solution
or use whatever means are currently available on the platform
(whatever that might be for Flash)?

Kind regards,
Marcos

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

Re: [widgets] dropping Asynchronous HTTP Requests and Storage

[Robin Berjon]

On Apr 7, 2009, at 06:37 , Jonas Sicking wrote:

On Mon, Apr 6, 2009 at 8:48 AM, Scott Wilson
 wrote:


On 6 Apr 2009, at 15:33, Anne van Kesteren wrote:

You will have this problem regardless of how you solve this issue  
if you
do not also require a specific scripting language, markup  
language, etc.



It seems to be rather strongly _implied_ that widgets will use HTML,
ECMAScript and CSS...


Could we also similarly imply that the .localStorage API also be
implemented? This is especially easy now that localStorage is becoming
its own spec [1].


Well, my understanding was that we had to have Web Storage for API &  
Events anyway since that's what implements preferences (and we need to  
define how it's used so that we can get read-only keys). Even if  
that's all there is, it'd be a little bit silly for a UA to support  
Web Storage for the preferences but not in other contexts.


--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/

Re: [widgets] dropping Asynchronous HTTP Requests and Storage

[Jonas Sicking]

On Mon, Apr 6, 2009 at 8:48 AM, Scott Wilson
 wrote:
>
> On 6 Apr 2009, at 15:33, Anne van Kesteren wrote:
>
>> You will have this problem regardless of how you solve this issue if you
>> do not also require a specific scripting language, markup language, etc.
>
>
> It seems to be rather strongly _implied_ that widgets will use HTML,
> ECMAScript and CSS...

Could we also similarly imply that the .localStorage API also be
implemented? This is especially easy now that localStorage is becoming
its own spec [1].

/ Jonas

[1] http://dev.w3.org/html5/webstorage/

Re: [widgets] dropping Asynchronous HTTP Requests and Storage

[Arthur Barstow]

On Apr 6, 2009, at 6:46 AM, ext Marcos Caceres wrote:


I had a discussion with Anne on IRC about using the Storage interface
and XHR [1]. He recommended that we recommend support for Storage only
on user agents that support HTML5. With regards to XHR, the same
applies: it would be a property of the underlying document technology.

So, proposal are: drop "Asynchronous HTTP Requests" requirement [2]  
and

remove its support from Widgets 1.0: A&E.


Regarding dropping XHR, Marcos and I chatted about this [1] and since  
none of the functionality in the A+E spec actually requires XRR, I  
agree with the proposal to remove the related statement in Section 3.1.


Regarding the requirement ([2] below), I think it is a reasonable  
requirement for a Widget User Agent so I would keep it despite none  
of our existing specs in progress address it (ATM).


-Regards, Art Barstow

[1] http://krijnhoetmer.nl/irc-logs/webapps/20090406



For Storage, specify that only
HTML-aware UAs support Storage interface.

Kind regards,
Marcos

[1] http://krijnhoetmer.nl/irc-logs/webapps/20090403#l-36
[2] http://dev.w3.org/2006/waf/widgets-reqs/#asynchronous-http- 
requests

Re: [widgets] dropping Asynchronous HTTP Requests and Storage

[Anne van Kesteren]

On Mon, 06 Apr 2009 16:26:15 +0200, Scott Wilson  
 wrote:

These are common practices that are ready to be standardised to
realize a benefit for widget developers and widget users.

The argument of "user agents having to support two storage mechanisms
for widgets" is a strawman: the cost for a UA to support the Widget
Preferences (Storage) API and wire it to their existing storage
implementation is trivial.


Maybe. It still increases QA cost (e.g. is the storage limit per API per  
widget or per widget, etc.) and confuses developers who have to pick one  
or the other.




However, the cost for widget developers to have to code multiple times
for different UAs - and the opportunity cost to users and UAs where
developers simply don't bother and end up sticking to developing for a
single UA - is far greater.


You will have this problem regardless of how you solve this issue if you  
do not also require a specific scripting language, markup language, etc.




The only debate is whether to standardize the existing practice (Apple/
Nokia/Opera method signatures) or attempt to harmonise with future
practice (use Web Storage method signatures).



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [widgets] dropping Asynchronous HTTP Requests and Storage

[Scott Wilson]

These are common practices that are ready to be standardised to  
realize a benefit for widget developers and widget users.


The argument of "user agents having to support two storage mechanisms  
for widgets" is a strawman: the cost for a UA to support the Widget  
Preferences (Storage) API and wire it to their existing storage  
implementation is trivial.


However, the cost for widget developers to have to code multiple times  
for different UAs - and the opportunity cost to users and UAs where  
developers simply don't bother and end up sticking to developing for a  
single UA - is far greater.


The only debate is whether to standardize the existing practice (Apple/ 
Nokia/Opera method signatures) or attempt to harmonise with future  
practice (use Web Storage method signatures).


S

On 6 Apr 2009, at 14:45, Anne van Kesteren wrote:

On Mon, 06 Apr 2009 15:28:47 +0200, Scott Wilson > wrote:

A consistent preferences interface is crucial for widget
interoperability; most of the widget platforms surveyed in the
Landscape document have a Preferences API - and have been pretty
consistent in how they've designed it. Its not exactly radical
standardisation practice to take 5 existing implementations and
harmonize them in a standard - in fact, not doing so is downright  
odd!


Why would you standardize on a storage API, but not on a markup  
language, markup language API, styling language, styling language  
API, scripting language, etc.? It doesn't make a whole lot of sense  
to me. Especially if it leads to user agents having to support two  
storage mechanisms for widgets if they happen to have one already.



--
Anne van Kesteren
http://annevankesteren.nl/




smime.p7s
Description: S/MIME cryptographic signature

Re: [widgets] dropping Asynchronous HTTP Requests and Storage

[Anne van Kesteren]

On Mon, 06 Apr 2009 15:28:47 +0200, Scott Wilson  
 wrote:

A consistent preferences interface is crucial for widget
interoperability; most of the widget platforms surveyed in the
Landscape document have a Preferences API - and have been pretty
consistent in how they've designed it. Its not exactly radical
standardisation practice to take 5 existing implementations and
harmonize them in a standard - in fact, not doing so is downright odd!


Why would you standardize on a storage API, but not on a markup language,  
markup language API, styling language, styling language API, scripting  
language, etc.? It doesn't make a whole lot of sense to me. Especially if  
it leads to user agents having to support two storage mechanisms for  
widgets if they happen to have one already.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [widgets] dropping Asynchronous HTTP Requests and Storage

[Scott Wilson]

Marcos,

A consistent preferences interface is crucial for widget  
interoperability; most of the widget platforms surveyed in the  
Landscape document [1] have a Preferences API - and have been pretty  
consistent in how they've designed it. Its not exactly radical  
standardisation practice to take 5 existing implementations and  
harmonize them in a standard - in fact, not doing so is downright odd!


A weak "you can use storage if you're on HTML5 otherwise do whatever  
you want about user's settings" is not a good solution - for widget  
developers this means you're going to have to build your widget  
differently for each UA and its native storage system. In which case,  
there isn't really much point in using a standard in the first place,  
right?


(Actually, what I'm sure many UA's would do in this case is adopt the  
approach taken by Opera, Nokia and Apple as the de-facto standard for  
Widget APIs.)


As for XHR - I don't think anyone would want to seriously drop this in  
real life. Unless your UA really is only designed to run clock and  
calculator widgets :-) Besides, its only a SHOULD not a MUST, right?


S


[1] http://www.w3.org/TR/2008/WD-widgets-land-20080414/#apis

On 6 Apr 2009, at 11:46, Marcos Caceres wrote:

I had a discussion with Anne on IRC about using the Storage  
interface and XHR [1]. He recommended that we recommend support for  
Storage only on user agents that support HTML5. With regards to XHR,  
the same applies: it would be a property of the underlying document  
technology.


So, proposal are: drop "Asynchronous HTTP Requests" requirement [2]  
and remove its support from Widgets 1.0: A&E. For Storage, specify  
that only HTML-aware UAs support Storage interface.


Kind regards,
Marcos

[1] http://krijnhoetmer.nl/irc-logs/webapps/20090403#l-36
[2] http://dev.w3.org/2006/waf/widgets-reqs/#asynchronous-http- 
requests






smime.p7s
Description: S/MIME cryptographic signature

[widgets] dropping Asynchronous HTTP Requests and Storage

[Marcos Caceres]

I had a discussion with Anne on IRC about using the Storage interface 
and XHR [1]. He recommended that we recommend support for Storage only 
on user agents that support HTML5. With regards to XHR, the same 
applies: it would be a property of the underlying document technology.


So, proposal are: drop "Asynchronous HTTP Requests" requirement [2] and 
remove its support from Widgets 1.0: A&E. For Storage, specify that only 
HTML-aware UAs support Storage interface.


Kind regards,
Marcos

[1] http://krijnhoetmer.nl/irc-logs/webapps/20090403#l-36
[2] http://dev.w3.org/2006/waf/widgets-reqs/#asynchronous-http-requests