[whatwg] Asynchronous database API feedback

[Oliver Hunt]

>> As a user, assuming a synchronous interface with timeouts, I would
>> almost certainly want my browser to enforce a _much_ shorter timeout
>> than 5 seconds... something on the order of 200ms, maybe.  Anything
>> that makes repainting stop just feels really bad.
>>
>>>> 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.
>>
>> I tend to agree.  Aaron, can you describe the thinking behind this
>> conclusion in more detail?
>
> It's just from attempting to use the API. It is pretty difficult. If
> you imagine some code that does synchronization of mail, it is going
> to be downloading items in batches. A simple schema might include
> messages, threads, and contacts. With a synchronous API, you just
> process these in a loop. Very straightforward.
>
> With an asynchronous API, it gets quite a bit messier. Here's an
> example of what it might look like:
>
> var messages = incoming_data;
>
> db.transaction(function(tx) {
>   processNextMessage(tx);
> });
>
> function processNextMessage(tx) {
>
>   if (!messages.length) return;
>
>   tx.executeSql("insert into messages (id, subject, body) values  
> (?, ?, ?)", [
> }

It's "easier" or "cleaner" aren't valid reasons to include a  
synchronous API.  Ignoring all
else, how do you define "easy"?

Certainly i don't think going through every use of an API to ensure  
it isn't doing large/long operations,
going through every possible configuration of desktop, laptop, mobile  
phone, and networked
storage configuration would be easy.  Then, if your web app does have  
code paths that require long
IO what happens?  Do you rewrite and redebug all of your code using  
the async API?  Or do you
come up with a magic size to determine when a synchronous operation  
will take too long (deriving the magic
size would itself require a large amount of testing)?  And at that  
point do you use a completely different
async path? or do you try to packetise your IO through the sync API  
to share code (which will not block
the browser but will likely make it sluggish)?

By providing a synchronous API you encourage the use of the "easy"  
stuff -- the synchro api -- but now
making sure you don't hork the users' browser becomes hard, and  
developers are unlikely to test
anywhere near enough.  All that will happen is that any site that  
uses the local storage api will be rendered
unusable on low end devices, or on any other configuration where IO  
to the "local" store is slower than
it is on the developers own system or network.

Your description of syncing
> With a synchronous API, you just process these in a loop. Very  
> straightforward.

Is a brilliant example of why a synchronous API is a bad idea.  What  
happens when the
list of messages, threads, and contacts becomes large?

When you enter JS the UI thread gets blocked, and now you are doing  
potentially large amounts of
blocking IO in JS.  You just blocked that UI thread.

--Oliver