On Thu, Mar 14, 2013 at 8:58 PM, Tab Atkins Jr. <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>
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.
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