Re: Indexed DB + Promises

On Wed, Sep 30, 2015 at 10:50 AM, Tab Atkins Jr. <jackalmage@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

Received on Wednesday, 30 September 2015 18:07:32 UTC