- From: Brady Eidson <beidson@apple.com>
- Date: Tue, 11 Dec 2007 12:17:57 -0800
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