I think that these shortcomings are also strengths. A synchronous localStorage is a drop-in replacement for cookies, which is a good thing to offer, and to encourage. Practically, if it's only cookies vs. IndexedDB (or SQL Database), I'd realistically choose the former for most code, and I'm sure that many Web developers would do the same.

It doesn't matter all that much if developers encode to JSON themselves or the engine does that, but adding a little syntactic sugar seems beneficial.

- WBR, Alexey Proskuryakov

02.06.2011, в 20:54, Darin Fisher написал(а):

I'm concerned that implementing this will only encourage more use of localStorage.  The API is very poor because it requires synchronous IO and synchronization between browser contexts, which may live on different threads.  (Note: Chrome does not implement the required synchronization.)

If we could fix localStorage to be asynchronous and transactional :-) then it'd be cool.  Of course, one answer is that people should just use IndexedDB.

FWIW, Jorlow (when he was still working on chrome) expressed similar sentiments.

On Jun 2, 2011 4:13 PM, "Maciej Stachowiak" <mjs@apple.com> wrote:
>
> Does anyone have an opinion on this Web Storage spec bug? The input of the WebKit community is desired. And probably Safari and Chrome folks in particular, if opinions differ.
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111
>
> http://dev.w3.org/html5/webstorage/#dom-storage-getitem says that "The
> getItem(key) method must return a structured clone of the current value
> associated with the given key." but all browsers I've tested return a string
> representation of the value instead."
>
> Regards,
> Maciej
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev