Re: DOM Storage feedback

On Jun 19, 2008, at 8:18 AM, Adam Roben wrote:

> 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.

You can just refuse to run scripts until the preload is done (same as  
you would if waiting for an external script to load). In this case  
there will be no UI hang. There are fancier implementations than that  
possible but this is a simple one that would be viable.

> 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.

I think that would be needless complexity.

Regards,
Maciej

Received on Thursday, 19 June 2008 17:11:52 UTC