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

On Thursday, March 14, 2013, Glenn Maynard wrote:

> On Thu, Mar 14, 2013 at 8:58 PM, Tab Atkins Jr. <jackalmage@gmail.com<javascript:_e({}, 'cvml', 'jackalmage@gmail.com');>
> > wrote:
>
>> The entire reason for most async (all?) APIs is thus irrelevant in a
>>
> Worker, and it may be a good idea to provide sync versions, or do
>> something else that negates the annoyance of dealing with async code.
>>
>
> I agree, except that async APIs are also useful and relevant in workers.
>  Sometimes you want synchronous code and sometimes you want asynchronous
> code, depending on what you're doing.
>
>
> On Thu, Mar 14, 2013 at 9:19 PM, Alex Russell <slightlyoff@google.com<javascript:_e({}, 'cvml', 'slightlyoff@google.com');>
> > wrote:
>
>> My *first* approach to this annoyance would be to start adding some async
>> primitives to the platform that don't suck so hard; e.g., Futures/Promises.
>> Saying that you should do something does not imply that doubling up on API
>> surface area for a corner-case is the right solution.
>
>
> "Futures" are nothing but a different async API.  They're in no way
> comparable to synchronous code.
>

I didn't imply they were. But addressing the pain point of asynchronous
code that's hard to use doesn't imply that the only answer is a synchronous
version. This is not a particularly hard or subtle point.


> But, as I said, it's true that a second synchronous interface isn't
> necessarily the best solution for complex APIs like IndexedDB.  At least in
> this particular case, if we have a synchronous messaging API I might call
> the synchronous IDB interface unnecessary.
>
> --
> Glenn Maynard
>
>