Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Wed, Mar 6, 2013 at 10:18 AM, Alex Russell <slightlyoff@google.com>wrote:

> So which part do you disagree with? That events are a bad model for a
> one-time action? Or that it's not clear what the expected contract is?
> Going by what you've written below, I have to assume the latter, so I'll
> just say this: try sitting a non-webdev down with IDB or any other DOM API
> that works this way and try to get them to figure it out from code samples.
> Yes, yes, being a webdev means knowing the platform idioms, but if we can
> agree they're confusing and difficult, we can start to do something about
> it. And in any case, you haven't refuted the former; events are simply a
> bad model here.
>

I disagree that events are bad for one-time actions, and I disagree DOM
events are confusing or difficult.

There's currently no other way to allow an API to be synchronous in workers
>> but only async in the UI thread.
>>
>
> Of course not...but what does that have to do with the price of fish? The
> core question is what's motivating a sync API here in the first place.
>

One of the primary reasons Web Workers exist is to allow writing linear,
synchronous code, because it's often inherently more convenient than
asynchronous code.  That requires synchronous APIs, so asynchronous APIs
typically gain a synchronous version when exposed to workers.  This isn't
the only way to go, and complex APIs like this may warrant giving the "sync
API for workers" thing another go, but it's the pattern today.

 I won't be responding to the rest of your message.
>

(FYI, if you're not replying to something, you don't have to say you're not
replying to it.  Just snip the quotes.)

On Wed, Mar 6, 2013 at 10:51 AM, Jarred Nicholls <jarred@webkit.org> wrote:

> I'm not understanding how this refutes the fact that single-fired events
> is an odd model for the job.  Sure it may be consistent, but it's
> consistently bad.  There are plenty of criteria for judging an API, one of
> which is consistency amongst the rest of the platform idioms.  But it
> should be no wonder that solid API developers come along and create
> comprehensible wrappers around the platform.
>

It's up to people claiming that it doesn't work well to demonstrate it; the
discussion started at "since DOM Events are bad for this...", assuming
everyone will automatically agree and skipping the step of actually arguing
that they're bad.  I find events to be simple and straightforward, so it
seems like a strange assumption to me.

I think this would be very desirable on all fronts to avoid duplication of
> interfaces; maybe something like signal events on which a caller can wait:
>
> var signal = someAsyncAction(),
>       result = signal.wait();
>

The discussion starts here, if you want to revive it (but it's fairly long,
with a few false starts, if I remember correctly):
http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0629.html

-- 
Glenn Maynard