- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 17 Dec 2010 10:27:00 -0800
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Pablo Castro <Pablo.Castro@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Fri, Dec 17, 2010 at 10:05 AM, Jeremy Orlow <jorlow@chromium.org> wrote: > On Fri, Dec 17, 2010 at 5:56 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> On Thu, Dec 16, 2010 at 4:39 PM, Jeremy Orlow <jorlow@chromium.org> wrote: >> > On Thu, Dec 16, 2010 at 10:09 PM, Pablo Castro >> > <Pablo.Castro@microsoft.com> >> > wrote: >> >> >> >> From: jorlow@google.com [mailto:jorlow@google.com] On Behalf Of Jeremy >> >> Orlow >> >> Sent: Thursday, December 16, 2010 2:35 AM >> >> >> >> >>In another thread (in the last couple days) we actually decided to >> >> >> remove timeouts from normal transactions since they can be >> >> >> implemented as a >> >> >> setTimeout+abort. >> >> >> >> >> >>But I agree that we need a way to abort setVersion transactions >> >> >> before >> >> >> getting the callback (so that we implement timeouts for them as >> >> >> well). >> >> >> Unfortunately, I don't immediately have any good ideas on how to do >> >> >> that >> >> >> though. >> >> >> >> Sorry, forgot to qualify it, context == sync api. I assume that the >> >> sync >> >> versions of the API will truly block, so setTimeout won't do as code >> >> won't >> >> just reenter into the timeout callback while blocked on a sync >> >> IndexedDB >> >> call, are we all on the same page on that? If that's the case, then I >> >> don't >> >> think we can remove the timeout parameter from the sync versions of >> >> transaction() and setVersion(). Does that sound reasonable? I'll add >> >> them >> >> for now, we can adjust if somebody come up with a better approach. >> >> >> >> As for setVersion in async...that's actually a problem as well now that >> >> I >> >> think about it because you don't have access to the (version) >> >> transaction >> >> object until it actually was able to start. One option besides having a >> >> timeout parameter in the method would be to have an abort() method in >> >> IDBVersionChangeRequest. >> > >> > Very good points.... >> > Given the fact that we will need timeouts for the sync version, I'm >> > starting >> > to wonder if it makes sense to just leave in for the async version. >> > Hm... >> > Jonas, what do you think? >> >> I'm fine with that, but I still don't think we should introduce the >> options object, given how rarely the timeout parameter is likely to be >> used. > > I'm still not sure we should keep it. It seems like a decent amont of API + > implementation for a feature that can be easily emulated. I guess we can > keep it for now though. > What about timeout/abort for async setVersion? How should we allow those? > Have abort() and ontimeout on the IDBRequest for just setVersion + a second > optional parameter to setVersion for the timeout? Seems like a heavyweight > solution, but I'm not sure how else to do it. We already have a separate IDBVersionChangeRequest interface, so adding ontimeout and abort() there should work. / Jonas
Received on Friday, 17 December 2010 18:27:55 UTC