[whatwg] Asynchronous database API feedback
ggaren at apple.com
Mon Dec 10 12:21:03 PST 2007
>> Getting back to storage, consider devices with a Flash drive as the
>> primary disk. Most web developers won't test on these (did you?), but
>> they have very different performance characteristics than hard
>> While there are no seek latencies to content with, and reads can be
>> pretty fast, the write throughput can be quite a bit worse,
>> for scattered small writes. In many cases, such devices have special
>> filesystems that try to spread writes over the entire device, to
>> increase Flash lifetime. But the result can be that write latencies
>> get much worse than usual at unpredictable times.
> I still feel that there are many simple use cases for a local database
> for which a developer can assume the read and write latency should
> always be less than five seconds.
Even the fastest desktop hard drives can show greater than 5 seconds
of latency under heavy load -- for example, while the user is
compiling, while Spotlight or Google Desktop is indexing the hard
drive, while many apps are starting up at the same time, etc. As long
as enough requests are pending in the OS's or the drive's read/write
queue, the browser has to wait.
Under what conditions can a web developer assume that no other
processes are using the hard drive?
I'd hate for GMail to mysteriously stop working every couple of days
just because of some background process that I had no knowledge of. As
a developer, how would you debug such a problem? As a tech support
worker, how would you explain it to an end user?
> If we cannot provide this, I feel that localstorage will not be
> successful, so it won't matter what API it uses.
I think this is a pretty extreme conclusion. My impression is that web
developers want local storage so badly, they'll use whatever API we
give them -- even if it's in Haskell :).
Anyway, if an API without synchronous access turns out to be
unpopular, we can always add synchronous access later. Whereas, if an
API with synchronous access turns out to hang the browser and make web
sites unreliable, we can't remove it later. So I think it's more
prudent to leave synchronous access out, and see what happens.
More information about the whatwg