- From: Pablo Castro <Pablo.Castro@microsoft.com>
- Date: Thu, 16 Dec 2010 22:09:38 +0000
- To: Jeremy Orlow <jorlow@chromium.org>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
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. Thanks, -pablo
Received on Thursday, 16 December 2010 22:10:12 UTC