LocalStorage spec and structured cloning
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
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
I'd advise commenting right in the w3c bugzilla, but if you don't feel like making an extra account I can copy in the below remarks for you. - Maciej On Jun 2, 2011, at 8:54 PM, Darin Fisher wrote:
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
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
You can't store much data in cookies and thus you're only shooting yourself in the foot with a bb gun. 5mb means you're shooting yourself in the foot with a real gun. And if you're allowing over 5mb, it's a bazooka. Anyway, I've written extensively about this many times on many different lists. Luckily for me, it doesn't look like I need to write yet again since it looks like I've convinced Jonas of my position. :-) J On Thu, Jun 2, 2011 at 10:04 PM, Alexey Proskuryakov <ap@webkit.org> wrote:
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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Fri, Jun 3, 2011 at 1:40 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
You can't store much data in cookies and thus you're only shooting yourself in the foot with a bb gun. 5mb means you're shooting yourself in the foot with a real gun. And if you're allowing over 5mb, it's a bazooka.
...and for this reason, Chromium will never give developers more than 5mb of localStorage space (even if we give them more space for other APIs). (I've lobbied for even reducing the space we hand out...not sure if that'll happen though.)
Anyway, I've written extensively about this many times on many different lists. Luckily for me, it doesn't look like I need to write yet again since it looks like I've convinced Jonas of my position. :-)
J
On Thu, Jun 2, 2011 at 10:04 PM, Alexey Proskuryakov <ap@webkit.org>wrote:
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.
Also note that such syntactic sugar breaks compat. (There's a concise example in the bug.) I think it's best just to leave localStorage as is... J
- 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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
participants (4)
-
Alexey Proskuryakov
-
Darin Fisher
-
Jeremy Orlow
-
Maciej Stachowiak