[webkit-dev] localStorage quota limit

[Jeremy Orlow]

After thinking about it a bit, I guess I feel like we should do nothing.

I'm pretty against letting users set the encoding type for localStorage.
 That sounds like a lot of complexity for not a lot of benifit.  Plus it'll
cause problems when multiple web apps are in the same origin (and require
different encoding) or you're using one JS library that assumes one encoding
and another that assumes another.

Converting to UTF 8 seems problematic.

Increasing the limit encourages heavier use of LocalStorage which I'm not in
favor of.  Darin's right that if you want to store a lot of data and/or have
more control over it, Web SQL Database is probably what you should be using.

J

On Wed, Dec 2, 2009 at 11:19 AM, Darin Fisher <darin at chromium.org> wrote:

> This is why LocalStorage quota should remain relatively small.  (/me holds
> back urges to bitch about the LocalStorage spec.)
>
> If people want more storage space, then DB should be used, which can more
> efficiently accommodate large amounts of data.
>
> -Darin
>
>
> On Wed, Dec 2, 2009 at 10:48 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
>> + hixie
>>
>> I don't know as much about encoding types as I should.  How can you
>> construct invalid UTF-16 sequences?  What does Firefox or IE do with these
>> when put into LocalStorage?
>>
>> One thing I just considered is that our LocalStorage implementation loads
>> the entire LocalStorage database for an origin into memory all at once.  It
>> does this on a background thread, but it's only loaded on the first access
>> to |window.localStorage| and we block on it finishing loading when you first
>> try to use it.  So if |alert(window.localStorage.foo);| is the first usage
>> of LocalStorage, it (and thus the main thread) will block on the whole thing
>> being loaded into memory.  This can certainly be optimized, but I'm pointing
>> this out because the bigger the DB is, the worse the worst case load time
>> is.  (Making this better is on my todo list, but not as near the top as I'd
>> like.)
>>
>> In case you're wondring, you can mitigate this by doing 'var storage =
>> window.localStorage;' as early as possible in your script and waiting as
>> long as possible to actually use window.localStorage.
>>
>> J
>>
>> On Wed, Dec 2, 2009 at 10:01 AM, Darin Adler <darin at apple.com> wrote:
>>
>>> On Dec 2, 2009, at 9:49 AM, Darin Fisher wrote:
>>>
>>> > This would probably be a performance win since it would reduce the
>>> amount of disk i/o.
>>> >
>>> > (Note, it doesn't mean that 5 million characters could be stored since
>>> a UTF-8 character might be multi-byte.)
>>>
>>> Currently the database can store invalid UTF-16 as well as valid UTF-16.
>>> Conversion from UTF-16 to UTF-8 might not be able to preserve invalid UTF-16
>>> sequences. I don’t understand how the other platforms handle this. Perhaps
>>> the specification needs to be clearer on whether invalid UTF-16 is allowed.
>>>
>>>    -- Darin
>>>
>>> _______________________________________________
>>> 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/20091202/427542a6/attachment.html>