On Dec 23, 2009, at 1:19 PM, William Edney wrote:
> From following the thread earlier, it didn't seem like anyone would have a
> major objection to using UTF-8 instead of UTF-16 for localStorage on Webkit.
Maciej did have an objection to doing this in a simplistic way (always using
UTF-8). He w
Folks -
Being the instigator of the 'localStorage quota limit' thread earlier in the
month, I'm curious as to where the discussion ended up.
I, with help with Jeremy Orlow :-), am interested in closing out:
https://bugs.webkit.org/show_bug.cgi?id=31791
From following the thread earlier, it did
On Dec 2, 2009, at 10:51 PM, Darin Fisher wrote:
Agreed. I was responding to your statement: "It's not clear to me
why Firefox or IE choose to reject instead of doing this." It seems
likely to me that neither Firefox nor IE made a concerted choice to
treat bad UTF-16 this way. It is p
On Wed, Dec 2, 2009 at 10:20 PM, Maciej Stachowiak wrote:
>
> On Dec 2, 2009, at 9:07 PM, Darin Fisher wrote:
>
> On Wed, Dec 2, 2009 at 8:44 PM, Maciej Stachowiak wrote:
>
>>
>> On Dec 2, 2009, at 8:14 PM, Darin Fisher wrote:
>>
>> What about Maciej's comment. JS strings are often use to store
On Dec 2, 2009, at 9:07 PM, Darin Fisher wrote:
On Wed, Dec 2, 2009 at 8:44 PM, Maciej Stachowiak
wrote:
On Dec 2, 2009, at 8:14 PM, Darin Fisher wrote:
What about Maciej's comment. JS strings are often use to store
binary values. Obviously, if people stick to octets, then it
should
On Wed, 2 Dec 2009, Maciej Stachowiak wrote:
> On Dec 2, 2009, at 8:14 PM, Darin Fisher wrote:
> > What about Maciej's comment. JS strings are often use to store binary
> > values. Obviously, if people stick to octets, then it should be fine,
> > but perhaps some folks leverage all 16 bits?
>
On Wed, Dec 2, 2009 at 8:44 PM, Maciej Stachowiak wrote:
>
> On Dec 2, 2009, at 8:14 PM, Darin Fisher wrote:
>
> What about Maciej's comment. JS strings are often use to store binary
> values. Obviously, if people stick to octets, then it should be fine, but
> perhaps some folks leverage all 16
On Dec 2, 2009, at 8:14 PM, Darin Fisher wrote:
What about Maciej's comment. JS strings are often use to store
binary values. Obviously, if people stick to octets, then it should
be fine, but perhaps some folks leverage all 16 bits?
I think some people do use JavaScript strings this way,
What about Maciej's comment. JS strings are often use to store binary
values. Obviously, if people stick to octets, then it should be fine, but
perhaps some folks leverage all 16 bits?
-Darin
On Wed, Dec 2, 2009 at 5:03 PM, Ian Hickson wrote:
> On Wed, 2 Dec 2009, Michael Nordman wrote:
> >
>
On Wed, 2 Dec 2009, Michael Nordman wrote:
>
> Arguably, seems like a bug that invalid string values are let thru the
> door to start with?
Yeah, I should make the spec through SYNTAX_ERR if there are any unpaired
surrogates, the same way WebSocket does. I'll file a bug.
--
Ian Hickson
On Dec 2, 2009, at 12:06 PM, Michael Nordman wrote:
Arguably, seems like a bug that invalid string values are let thru
the door to start with?
ECMAScript Strings are essentially sequences of arbitrary 16-bit
values. Sometimes Web apps take advantage of this to use a String as a
hacky way
Arguably, seems like a bug that invalid string values are let thru the door
to start with?
Since users can't effectively store invalid UTF16 character sequences in FF
or IE, is there really any downside to using UTF8 text encoding in WebKit?
@Jeremy, this isn't a matter of letting users choose the
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
di
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 Orl
IE chokes ("invalid procedure call or argument") and Firefox mangles the
data for LocalStorage (but works fine for SessionStorage).
On Wed, Dec 2, 2009 at 10:54 AM, Darin Adler wrote:
> On Dec 2, 2009, at 10:48 AM, Jeremy Orlow wrote:
>
> > How can you construct invalid UTF-16 sequences?
>
> htt
On Dec 2, 2009, at 10:48 AM, Jeremy Orlow wrote:
> How can you construct invalid UTF-16 sequences?
http://unicode.org/faq/utf_bom.html#utf16-7
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinf
+ 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 orig
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 inval
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.)
-Darin
On Wed, Dec 2, 2009 at 9:30 AM, Michael Nordman wrote:
> Could WebKit configure the local
Could WebKit configure the localstorage database(s) to use UTF8 text
encoding for string values?
On Sun, Nov 29, 2009 at 8:38 AM, William Edney
wrote:
> All -
>
> I've been discussing the localStorage quota limit over on this bug with
> Jeremy Orlow:
>
> https://bugs.webkit.org/show_bug.cgi?id=31
All -
I've been discussing the localStorage quota limit over on this bug with Jeremy
Orlow:
https://bugs.webkit.org/show_bug.cgi?id=31791
To recap from the discussions on that bug:
Jeremy has implemented the localStorage quota on the latest Webkit builds. This
caused my usage of localStorage
21 matches
Mail list logo
