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 to represent binary data. I don't think we should reject such strings arbitrarily.
Since users can't effectively store invalid UTF16 character sequences in FF or IE,
I tend to think this is a bug in FF/IE. Nothing in the spec gives license to reject particular Strings.
is there really any downside to using UTF8 text encoding in WebKit? @Jeremy, this isn't a matter of letting users choose the text encoding, this is entirely an implementation detail of WebStorage.
I think it would be fine to use a more compact encoding opportunistically, as long as we can still handle an arbitrary JavaScript String. Perhaps we should use UTF-8 if and only if the conversion succeeds, or perhaps even use Latin1 as the alternative.
Downsides
* The code change to get UTF8 by default in new databases, tiny.
* Migrating pre-existing databases to the new encoding. Somewhat of a hassle. But maybe doesn't need to be done, pre-existing files could continue to use UTF16, while newly created dbs could use UTF8 (the text encoding is chosen at database creation time and stuck that way forever thereafter).
* Its possible that some app is already depending on the ability to store invalid character sequences (on the iPhone say), and this would be a breaking change for that app.
The preload everything characteristic is a separate issue altogether.
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev