W3C home > Mailing lists > Public > www-tag@w3.org > November 2011

Re: TAG Comment on

From: Adam Barth <w3c@adambarth.com>
Date: Sun, 20 Nov 2011 15:42:03 -0800
Message-ID: <CAJE5ia-RHekYvB59tEZUdrQJMFig0-qR=3a9DyC6qhWWOtLAHg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Noah Mendelsohn <nrm@arcanedomain.com>, public-webapps@w3.org, "www-tag@w3.org" <www-tag@w3.org>
On Sun, Nov 20, 2011 at 3:30 PM, Mark Nottingham <mnot@mnot.net> wrote:
> Yes, if you configure your browser to do so, you'll be assaulted with requests for a "test db" from many Web sites that use common frameworks.
>
> I don't think that this should count as "use."

Indeed.  That is not the sort of use I'm referring to.

> I do think now is precisely the time to be asking this kind of question; these features are NOT yet used at *Web* scale -- they're used by people willing to live on the bleeding edge, and therefore willing to accept risk of change.

You're welcome to tilt at that windmill, but the chance that you get
these APIs removed from browser is approximately zero.

Adam


> One of the problems with lumping in a lot of new feature development with a spec maintenance / interop effort is confusion like this. Hopefully, the W3C (and others) will learn from this.
>
>
>
> On 16/11/2011, at 9:47 AM, Adam Barth wrote:
>
>> These APIs are quite widely used on the web.  It seems unlikely that
>> we'll be able to delete either of them in favor of a single facility.
>>
>> Adam
>>
>>
>> On Tue, Nov 15, 2011 at 2:05 PM, Noah Mendelsohn <nrm@arcanedomain.com> wrote:
>>> This is a comment from the W3C Technical Architecture Group on the last call
>>> working draft: "Web Storage" [1].
>>>
>>> The HTML5 Application Cache (AppCache) [2] and Local Storage [1] both
>>> provide client-side storage that can be used by Web Applications. Although
>>> the interfaces are different (AppCache has an HTML interface while Local
>>> Storage has a JavaScript API), and they do seem to have been designed with
>>> different use cases in mind, they provide somewhat related facilities: both
>>> cause persistent storage for an application to be created, accessed and
>>> managed locally at the client. If, for example, the keys in Local Storage
>>> were interpreted as URIs then Local Storage could be used to store manifest
>>> files and Web Applications could be written to look transparently for
>>> manifest files in either the AppCache or in Local Storage. One might also
>>> envision common facilities for querying the size of or releasing all of the
>>> local storage for a given application.
>>>
>>> At the Offline Web Applications Workshop on Nov 5, 2011 [3] there was a
>>> request for a JavaScript API for AppCache and talk about coordinating
>>> AppCache and Local Storage.
>>>
>>> The TAG believes it is important to consider more carefully the potential
>>> advantages of providing a single facility to cover the use cases, of perhaps
>>> modularizing the architecture so that some parts are shared, or if separate
>>> facilities are indeed the best design, providing common data access and
>>> manipulation APIs. If further careful analysis suggests that no such
>>> integration is practical, then, at a minimum, each specification should
>>> discuss how it is positioned with respect to the other.
>>>
>>> Noah Mendelsohn
>>> For the: W3C Technical Architecture Group
>>>
>>> [1] http://www.w3.org/TR/2011/WD-webstorage-20111025/
>>> [2] http://www.w3.org/TR/html5/offline.html#appcache
>>> [3] http://www.w3.org/2011/web-apps-ws/
>>>
>>>
>>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
Received on Sunday, 20 November 2011 23:43:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:40 GMT