[whatwg] Asynchronous database API feedback

[Geoffrey Garen]

>> 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  
>> drives.
>> While there are no seek latencies to content with, and reads can be
>> pretty fast, the write throughput can be quite a bit worse,  
>> especially
>> 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.

Geoff