- From: Aaron Boodman <aa@google.com>
- Date: Fri, 5 Mar 2010 09:22:11 -0800
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Nikunj Mehta <nikunj@o-micron.com>, Kris Zyp <kris@sitepen.com>, public-webapps WG <public-webapps@w3.org>
On Fri, Mar 5, 2010 at 4:54 AM, Jeremy Orlow <jorlow@chromium.org> wrote: > For what it's worth, regardless of the answers to the above questions, I > think we should switch to a callback based model. It's great to use events > when natural to do so, but this is a very unnatural use. It provides > artificial limitations (only one request in flight at a time, per request > object). It's ugly and confusing syntax wise (hard to keep track of which > request object is associated with which request method, requires multiple > statements to do each request, requires the handlers to be placed prior to > the actual call...which is why the async example > in http://www.w3.org/TR/IndexedDB/#introduction is so difficult to read, > etc). And there really isn't any precedent (that I'm aware of) for using > events like this. And the web developers I've spoken to have all been > confused by the async API. I agree the current model is confusing. It looks like it is emulating DOM events like document.onclick. That is fine when there is only one document, but it makes no sense when you specifically create each request, but you have to listen for the result on a shared onrequest object. What happened to following the pattern of SQLDatabase. Other than the fact that it was SQL, I thought that was pretty elegant. It can also be easily made to work synchronously if that is a requirement. - a
Received on Friday, 5 March 2010 17:22:49 UTC