On Mon, Oct 5, 2015 at 3:27 PM, Joshua Bell <jsb...@google.com> wrote:
> Thanks for all the feedback so far. I've captured concrete suggestions in > the issue tracker - > https://github.com/inexorabletash/indexeddb-promises/issues > > > > On Wed, Sep 30, 2015 at 11:10 AM, Tab Atkins Jr. <jackalm...@gmail.com> > wrote: > >> On Wed, Sep 30, 2015 at 11:07 AM, Kyle Huey <m...@kylehuey.com> wrote: >> > On Wed, Sep 30, 2015 at 10:50 AM, Tab Atkins Jr. <jackalm...@gmail.com> >> wrote: >> >> On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola <d...@domenic.me> >> 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. > > Dusting this off. Any additional feedback? If we gain implementation experience and handle the details tracked at https://github.com/inexorabletash/indexeddb-promises/issues does this approach seem like viable path forward for other implementers?
