Re: RE : Sync IO APIs in Shared Workers

On Wed, Dec 4, 2013 at 6:38 PM, Charles Pritchard <chuck@jumis.com> wrote:

> 1) Sync APIs are inherently easier to use than async ones, and they are
>> much
>> less error prone. JS developers are not C++ developers. Whenever
>> possible, it's
>> just better to make things more simpler and convenient.
>>
>
> This argument is not particularly helpful.


I don't know what "JS developers are not C++ developers" means, but it's
definitely true that it's better to provide convenient interfaces.


> Apart from that, many JS APIs use callbacks,
> all developers are-or-have to be aware of them.


Just because we can develop in more cumbersome environments isn't an
argument that we should have to.


> Devs are already in an async world when doing JS.
>

This isn't an argument that they should *have* to be.

It's not particularly fun re-writing async methods from the webpage to be
> sync for workers, or otherwise using shims to avoid redundancy.


(What?  Nobody is arguing that async APIs shouldn't be exposed in workers.)


> The extra semantic load on the namespaces (docs and otherwise) isn't all
> that pleasing either. There is a cost.
>

Yes, there's definitely a cost.  It would help a lot if things were
designed so that a sync API followed from the async API implicitly, instead
of always having to expose a separate interface.  For example, a
select()-like interface to block until the first completion from a list of
running async operations (among other things, such as MessagePorts to wake
on receipt of a message) would allow using async APIs as-is in a
synchronous way, without the need to expose a separate sync API for each
async API.

It would also solve the problem of not being able to interrupt synchronous
APIs, since the developer could--at his option--wait for both a long
operation and the receipt of a message on a "cancel what you're doing"
message port, whichever comes first, while still being able to write code
in a linear fashion.

-- 
Glenn Maynard