How many ways to save store app data?
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?
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
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
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?
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