[webkit-dev] LocalStorage spec and structured cloning

[Jeremy Orlow]

On Fri, Jun 3, 2011 at 1:40 AM, Jeremy Orlow <jorlow at 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 at 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 at 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 at lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110603/d3b40d69/attachment.html>