[whatwg] Asynchronous database API feedback

[Aaron Boodman]

On Dec 9, 2007 1:59 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> > a) Disk access is typically going to be a lot faster than network
> > access
>
> I think this assumption is, if not exactly incorrect, somewhat
> misleading.
>
> For users on network home directories, disk access /is/ network
> access. This is a common setup at large corporations and educational
> institutions. We have specific experience with WebKit that doing
> sqlite database access from the UI thread resulted in frequent long UI
> stalls for Apple's users on network home directories.(*)
>
> Now, you might argue that network home directories are not "typical"
> and this is true, but the web application has no way to know when it
> might hit the atypical case and thereby block the user's UI, just as
> with synchronous XMLHttpRequest you have no way to know when the user
> is on a slow network connection.
>
> So I continue to believe that it's not safe to do synchronous I/O from
> the UI thread.

In the case of Firefox and IE on Windows and Mac at least (I don't
recall the situation with Safari), Gears' sqlite database is stored in
the Caches or "Local Settings" folder which, as I understand it, is
meant to be on the local drive.

Since part of the purpose of this API is to allow offline access, it
doesn't seem to make sense to put the data on a network drive, at
least for devices that are mobile.

> Another important consideration: even ignoring distributed
> filesystems, how do web application developers decide when the writes
> they are doing are definitely small enough that it's safe to use the
> sync API?
>
> Your test shows 3KB written in a tenth of a second, but datastores
> could easily be much larger than that. If the time scales linearly,
> then even a modest 300KB of data could take 10 seconds to write,
> clearly an unacceptable amount of time to stall the UI (I hope it
> doesn't scale linearly because that would be alarmingly slow, but
> clearly at some size it gets slow).

There are many different use cases for the local database and a
developer can make reasonable assumptions about how large the queries
are going to be in many cases. For example, pulling up all the data
required to render the first view of Reader is a totally different
kind of query than updating the read or starred state of an individual
item.

> Given how wildly hardware varies, I'm not sure how web developers can
> safely make this choice. It seems likely that they'd choose whatever
> seems to work for them in simple cases, and not test at all on slower
> filesystems. If the queries they do vary in size, they may not test at
> extreme sizes. These are the same kinds of cases where synchronous XHR
> creates surprising problems - it seems ok on the developer's fast
> local network, so why expect that end users will see a problem?

It's a similar situation to XHR, but I think the parameters are different:

a) Synchronous network access is almost never be a good idea, but in
our experience synchronous local disk access via SQLite is frequently
fine.

b) XHR defaults to synchronous -- you have to add an optional third
parameter to make it asynchronous. That probably contributes somewhat
to the confusion. What I am proposing is a peer to the asynchronous
API. This would hopefully encourage developers to consciously choose
which one to use rather than just not realizing that the default is a
bad idea.

- a