[whatwg] Asynchronous database API feedback

On Dec 9, 2007 3:52 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> On a mobile device, it doesn't make sense for your home directory to
> be on a network drive either. However, if you use one of several
> shared workstations, you probably want your local data to be there
> when the rest of your homedir is.

I don't think this is true. For the applications we have built with
Gears, the local data is a cache of the truth which is on the server.
Two major reasons for having local data is that a) it's fast, and b)
it will be there when you unexpectedly go offline. Both of these are
lost if the "local" data is actually on a network drive.

> I'll be more convinced if there's a better answer to this than "make
> reasonable assumptions".
>
> Thinking about it now, I can imagine a way to make this more concrete:
> give synchronous transactions a time limit, and if they exceed it they
> report an error and fail. We can be generous and say the limit is 5
> seconds, although that's awful close to unacceptable UI lockup
> territory. Possible drawbacks:

Ok, that sounds good. Actually that is the way we have implemented
Gears today, and I guess I assumed that a timeout was part of the
picture. We have a five-second timeout on the database and what we
have told developers is that if you are getting timeout errors,
something is dreadfully wrong, you should not try again but
investigate why this is happening.

> - I'm not sure it will be any easier to handle timeout errors than it
> would be to use the async API (since, if your request is too big to
> complete in reasonable time on this device, you probably have to use
> the async API as your fallback).

Or just let it be an error :-). If you start hearing this from
developers, you probably change your app to use only the async API in
that case, or report it to the vendor (you or I) and say "why is it
taking 5 seconds to select 1 row? Is there a bug?".

> Thoughts? Would you be willing to use a synchronous API with a
> timeout? Do you think it's reasonable for other web developers? (I'm
> honestly not sure, I haven't thought it through in detail.)

I think it's reasonable. Sorry I assumed the design already implied
something like this.

> 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. If we cannot provide this, I feel
that localstorage will not be successful, so it won't matter what API
it uses.

- a

Received on Sunday, 9 December 2007 12:18:48 UTC