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
