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