- From: Adam Roben <aroben@apple.com>
- Date: Thu, 19 Jun 2008 11:18:49 -0400
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Ian Hickson <ian@hixie.ch>, Zhenbin Xu <Zhenbin.Xu@microsoft.com>, Ian Hickson <IMCEAMAILTO-ian+40hixie+2Ech@windows.microsoft.com>, "public-html-comments@w3.org" <public-html-comments@w3.org>, public-html@w3.org, Sunava Dutta <sunavad@windows.microsoft.com>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>
Maciej Stachowiak wrote: > On Jun 18, 2008, at 10:38 PM, Ian Hickson wrote: >> It would be useful to get feedback from other implementors on this. > > [...] > >>>> The API is designed in such a way that UAs can implement a lazy commit >>>> on the back end, but this should not be exposed to the author -- there >>>> is no reason for the author to need to know whether the data is in >>>> RAM, flash storage, disk storage, remote tape storage, or whatever. >>> >>> There is clearly an advantage to expose this concept to authors -- just >>> like they need to know network can be slow so better use async XHR >>> rather than sync XHR -- storage operation can be very slow. Sync DOM >>> Storage operation is a potential hang point, >> >> The idea is that the storage is asynchronous (and under the control >> of the >> UA), but that the API appears synchronous. That is, as soon as one >> script >> sets a storage item to a particular value, the setter will return >> with no >> latency, and all attempts from any frames to read that same storage item >> will give the new value back. It doesn't have to be stored to disk >> immediately, however. Since this is a simple name/value text-only >> API, it >> is trivially cached in memory. [...] > In WebKit we have implemented DOM Storage with a synchronous API, but > ahead-of-time read and lazy writeback, using something roughly like > the strategy Hixie describes. I've been worried a bit recently about the synchronous API for reading from localStorage. It seems like it would be very common for pages to access localStorage early in the lifetime of the page to restore state from the last browsing session, and even with an ahead-of-time read it's entirely possible that we won't have finished reading off the disk by the first access. In this case, the whole browser will hang. One possible solution to this problem would be to have an event that fires when localStorage is ready for reading (perhaps called "localstorageready"). Before that event fires, all attempts to read from localStorage will fail (perhaps writes should fail as well, for consistency?). After the event fires, localStorage can be used normally. -Adam
Received on Thursday, 19 June 2008 15:19:31 UTC