Re: [IndexedDB] Callback order

On Fri, Jun 18, 2010 at 7:24 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Fri, Jun 18, 2010 at 7:01 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > I think determinism is most important for the reasons you cited.  I think
> > advanced, performance concerned apps could deal with either semantics you
> > mentioned, so the key would be to pick whatever is best for the normal
> case.
> >  I'm leaning towards thinking firing in order is the best way to go
> because
> > it's the most intuitive/easiest to understand, but I don't feel strongly
> > about anything other than being deterministic.
>
> I definitely agree that firing in request order is the simplest, both
> from an implementation and usage point of view. However my concern is
> that we'd lose most of the performance benefits that cursors provide
> if we use that solution.
>
> What do you mean with "apps could deal with either semantics"? You
> mean that they could deal with the cursor case by simply being slower,
> or do you mean that they could work around the performance hit
> somehow?
>

Hm.  I was thinking they could save the value, call continue, then do work
on it, but that'd of course only defer the slowdown for one iteration.  So I
guess they'd have to store up a bunch of data and then make calls on it.

Of course, they'll run into all of these same issues with the sync API since
things are of course done in order.  So maybe trying to optimize this
specific case for just the async API is silly?

J