How many ways to save store app data?

2011-03-28 Thread Arthur Barstow

Hi All,

Louis-rémi's thread [1] on AppCache led to discussions about other 
storage related APIs including DataCache, Google Gears, IDB and the File 
* APIs.


Are there are any good resources that describe the various storage APIs 
(from the app developer's perspective) and compare their main properties 
such as: primary Use Cases addressed, strengths, weaknesses, 
implementation and deployment status, performance characterizations, 
security concerns, features planed for next version, etc.? The APIs of 
interest include: HTML5 AppCache, DataCache, File * APIs, Google Gears, 
Indexed Database, Web Storage, and Web SQL Database.


In the absence of such resource(s), would anyone be interested in 
leading, or contributing to, an informative document like this?


WebApps does have a related wiki document that was created primarily to 
rationalize the start of the IDB spec vis-à-vis Web SQL Database. This 
document hasn't been touched in over a year and probably needs updating:


   http://www.w3.org/2008/webapps/wiki/Database

-Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/1043.html






[widgets] Widget Updates tests?

2011-03-28 Thread Scott Wilson
Hi everyone,

Are there any tests available - even informal ones - for the Widget Updates[1] 
spec?

Cheers,

S

[1] http://www.w3.org/TR/widgets-updates/


Re: SearchBox API

2011-03-28 Thread Sean Eagan
Why not just build this on top of web messaging[1] by having a
browsing context associated with the search box (or entire browser
chrome) that can communicate with a SERP or any page that wants to
accept input from a search box or otherwise communicate directly with
a user agent?

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

On Mon, Mar 21, 2011 at 1:38 PM, Adam Barth w...@adambarth.com wrote:
 On Mon, Mar 21, 2011 at 11:16 AM, Edward Lee edi...@mozilla.com wrote:
 enables instant style interaction between the user agent's search
 Assuming the user agent automatically loads a url that is triggered by
 a user key stroke, e.g., typing g results in
 http://www.google.com/;, the instant-style interaction is almost
 there already for certain urls. These instant-style urls would include
 what the user typed -- perhaps as a query parameter.

 For example, a user agent might request these pages as the user types:
 http://www.google.com/search?q=g
 http://www.google.com/search?q=go
 http://www.google.com/search?q=goo

 Here, the results page shows the new query and updated results on
 every user keystroke.

 These instant-style urls can also avoid refetching and rerendering the
 whole page if the user's input shows up in the #fragment and the page
 detects onHashChange.

 That's true, but you can only transmit one event that way.  In this
 design, you've chosen to map the change event to hashchange.  How
 should the user agent communicate that the user is done typing (i.e.,
 the submit event, which triggers when presses the enter key)?
 Similarly, the communication in that approach is unidirectional, which
 means the page can't suggest search completions.

 Adam





-- 
Sean Eagan



[FileAPI] Result of calling MultipleReads on FileReader

2011-03-28 Thread Adrian Bateman
As we continue to experiment with the File API, I'm trying to understand the
rationale for the Multiple Reads section:
http://dev.w3.org/2006/webapi/FileAPI/#MultipleReads

The spec says:

   If multiple read methods are called on the same FileReader object, user
   agents MUST only process the last call to a read method, which is the
   call that occurs last in a script block that has the already started
   flag set [HTML5].

I'm trying to understand the rationale for respecting the LAST call - is it
common for people to call read lots of times and want the last one to be
respected. Since the read happens asynchronously, we'd rather kick off the
read operation as soon as the first read is called and give an error to
subsequent read calls. I'm not sure what the use case is for wanting the last
one (you can always call abort() and start again).

Is there a reason for the current spec text?

Thanks,

Adrian.

-- 
Adrian Bateman
Program Manager - Internet Explorer - Microsoft Corporation
Phone: +1 (425) 538 5111
Email: mailto:adria...@microsoft.com





Re: How many ways to save store app data?

2011-03-28 Thread Michael Nordman
Not sure if this is what you're looking for, but the
http://www.html5rocks.com/ site provides a developer facing view of these
things.

On Mon, Mar 28, 2011 at 6:21 AM, Arthur Barstow art.bars...@nokia.comwrote:

 Hi All,

 Louis-rémi's thread [1] on AppCache led to discussions about other storage
 related APIs including DataCache, Google Gears, IDB and the File * APIs.

 Are there are any good resources that describe the various storage APIs
 (from the app developer's perspective) and compare their main properties
 such as: primary Use Cases addressed, strengths, weaknesses, implementation
 and deployment status, performance characterizations, security concerns,
 features planed for next version, etc.? The APIs of interest include: HTML5
 AppCache, DataCache, File * APIs, Google Gears, Indexed Database, Web
 Storage, and Web SQL Database.

 In the absence of such resource(s), would anyone be interested in leading,
 or contributing to, an informative document like this?

 WebApps does have a related wiki document that was created primarily to
 rationalize the start of the IDB spec vis-à-vis Web SQL Database. This
 document hasn't been touched in over a year and probably needs updating:


   http://www.w3.org/2008/webapps/wiki/Database

 -Art Barstow

 [1]
 http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/1043.html