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.


Reply via email to