Thanks for all the feedback so far. I've captured concrete suggestions in
the issue tracker -

On Wed, Sep 30, 2015 at 11:10 AM, Tab Atkins Jr. <>

> On Wed, Sep 30, 2015 at 11:07 AM, Kyle Huey <> wrote:
> > On Wed, Sep 30, 2015 at 10:50 AM, Tab Atkins Jr. <>
> wrote:
> >> On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola <>
> wrote:
> >>> I guess part of the question is, does this add enough value, or will
> authors still prefer wrapper libraries, which can afford to throw away
> backward compatibility in order to avoid these ergonomic problems? From
> that perspective, the addition of waitUntil or a similar primitive to allow
> better control over transaction lifecycle is crucial, since it will enable
> better wrapper libraries. But the .promise and .complete properties end up
> feeling like halfway measures, compared to the usability gains a wrapper
> can achieve. Maybe they are still worthwhile though, despite their flaws.
> You probably have a better sense of what authors have been asking for here
> than I do.
> >>
> >> Remember that the *entire point* of IDB was to provide a "low-level"
> >> set of functionality, and then to add a sugar layer on top once
> >> authors had explored the space a bit and shown what would be most
> >> useful.
> >>
> >> I'd prefer we kept with that approach, and defined a consistent,
> >> easy-to-use sugar layer that's just built with IDB primitives
> >> underneath, rather than trying to upgrade the IDB primitives into more
> >> usable forms that end up being inconsistent or difficult to use.
> >
> > At a bare minimum we need to actually specify how transaction
> > lifetimes interact with tasks, microtasks, etc.  Especially since the
> > behavior differs between Gecko and Blink (or did, the last time I
> > checked).

Yeah - "When control is returned to the event loop" isn't precise enough.
It's an open issue in the 2nd Ed. and I welcome suggestions for tightening
it up. Note that Jake Archibald, at least, was happy with the Blink
behavior, after chewing on it for a bit. But it still seems far too subtle
to me, and someone who writes blog posts explaining tasks vs. microtasks is
probably not the average consumer of the API. :)

> >
> > waitUntil() alone is a pretty large change to IDB semantics. Somebody
> > mentioned earlier that you can get this behavior today which is true,
> > but it requires you to continually issue "keep-alive" read requests to
> > the transaction, so it's fairly obvious you aren't using it as
> > intended.
> Yeah, any necessary extensions to the underlying "bare" IDB semantics
> that need to be made to support the sugar layer are of course
> appropriate; they indicate an impedance mismatch that we need to
> address for usability.

Agreed.  So... I'm looking for additional feedback that the proposal
addresses this mismatch, with both waitUntil() on transactions (kudos to
Alex Russell) and the promise accessors on transactions/requests and minor
cursor tweaks which difficult to get correct today.

Reply via email to