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

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

- Kyle

Reply via email to