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. > > ~TJ >
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). 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. - Kyle
