Re: TAG Comment on

The idea is not to remove APIs.

We have several client-side storage facilities that cover different but overlapping
usecases.  Can we step back and look at what we have and come up, perhaps, with a
smaller set of facilities and better coordinated APIs.
All the best, Ashok

On 11/20/2011 3:42 PM, Adam Barth wrote:
> 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 Monday, 21 November 2011 01:33:56 UTC