- From: James Robinson <jamesr@google.com>
- Date: Sat, 11 Jun 2011 12:57:57 -0700
- To: Arthur Barstow <art.barstow@nokia.com>
- Cc: ext Ian Hickson <ian@hixie.ch>, public-webapps <public-webapps@w3.org>
- Message-ID: <BANLkTikezz=7w8xZKP+xRqLgp+_9ohxrHA@mail.gmail.com>
On Sat, Jun 11, 2011 at 4:32 AM, Arthur Barstow <art.barstow@nokia.com>wrote: > On Jun/10/2011 3:05 PM, ext Ian Hickson wrote: > >> On Fri, 10 Jun 2011, Arthur Barstow wrote: >> >>> > >>> > My take on the comments is that most commentors prefer the spec to be >>> > changed as PLH suggested in comment #5: >>> > > http://www.w3.org/Bugs/Public/**show_bug.cgi?id=12111#c5<http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111#c5> >>> > > Hixie - are you willing to change the spec accordingly? >>> >> What's the rush here? This is a minor issue, which I plan to address in >> due course. It's not blocking implementors, it's not causing any >> interoperability trouble, it's not stopping someone from writing a test >> suite, why all the fuss? >> > > I would like all of the group's specs to keep moving forward on the > Recommendation track. That is an expectation set forth in the group's > charter and I don't think I have ever asked the group to "rush" this or any > other spec. (On the contrary, I have supported longer review periods when > requested and do not enforce the 90-day heartbeat publication policy "just > to publish".) > > In this case, at least one other spec (which is planned for Proposed > Recommendation in early August) has a normative dependency on Storage (and > these functions in particular). Although the reference policy provides some > flexibility, I think it is sub-optimal for later stage specs to depend on > specs that are still changing. > > I would appreciate it, if you would please provide a date when you expect > to have addressed this issue. > > (FYI, Cam is working on a schedule to move Web IDL to LC which is the only > other dependency not yet at LC for the spec mentioned above.) > > -AB > > I am speaking only for myself (and not Google, WebKit, or Chromium) but I feel obligated to point out that localStorage specifies a fundamentally broken synchronization model that we are not able to fix due to compatibility concerns. This is noted at http://dev.w3.org/html5/webstorage/#issues with a tragically optimistic request for suggestions. As an implementor, my main motivation to pay any attention to localStorage is to think up ways to discourage authors from using it for anything non-trivial. In my opinion, the only thing left to be done with localStorage is to write it off as an unfortunate failure, learn our lesson, and move on. This may not be relevant to the processes you are trying to follow. - James
Received on Saturday, 11 June 2011 19:58:22 UTC