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
