Re: [IndexedDB] Do we need a timeout for VERSION_CHANGE?

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.

J