W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2007

[whatwg] Asynchronous database API feedback

From: Brady Eidson <beidson@apple.com>
Date: Tue, 11 Dec 2007 12:17:57 -0800
Message-ID: <7F0BE595-A2A5-4F8C-8646-30F7F9E51B5C@apple.com>

On Dec 11, 2007, at 11:40 AM, Aaron Boodman wrote:

> I thought it would be useful if the spec had a simple synchronous API
> for cases where the developer expects operations to happen quickly
> and/or doesn't care if they timeout ocassionally (because, for
> example, the application will retry automatically later).

I think the assertion of many here is that the web developer *can't*  
have any knowledge about whether or not the operation will happen  
quickly...
If the application's solution is to handle timeouts and try again  
later, what if their execution environment doesn't change?

Such as the user is playing a system-intensive game, or transferring a  
large amount of HD video, or any other disk-intensive task that is  
long running.
Or the user is on limited power device that will always be slower, and  
the query the application is trying to execute is *just* over the  
timeout threshold, and it will never be fast enough.
And I can think of a lot more!

This application will never succeed in storing its data, and the  
developer/user won't have any recourse.

In this case we've given the application developer the tool to shoot  
themselves in the foot and they won't even know it.

> It's clear that most people here feel passionately that this is the
> wrong thing to do. Perhaps it's best that we table this until
> something like workerpools are in the spec.

I don't see the advantage of replacing a targeted form of  
asynchronicity that has some consensus with a general purpose form of  
asynchronicity that brings a lot of other concerns/debate along with it

~Brady
Received on Tuesday, 11 December 2007 12:17:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:59 UTC