- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 30 Sep 2015 10:50:50 -0700
- To: Domenic Denicola <d@domenic.me>
- Cc: Joshua Bell <jsbell@google.com>, "public-webapps@w3.org" <public-webapps@w3.org>
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
Received on Wednesday, 30 September 2015 17:51:39 UTC