[webrtc-pc] Operations "queue" is a misnomer. Confuses people. (#2227)

jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc:

== Operations "queue" is a misnomer. Confuses people. ==
With my editor's hat on, there's [evidence](https://github.com/w3c/webrtc-pc/pull/2212#discussion_r303013577) "[enqueuing an operation](https://w3c.github.io/webrtc-pc/#enqueue-an-operation)" is confusing. Readers confuse it with [queue a task](https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-task), a wildly different concept.

It's understandable, because our [operations queue](http://w3c.github.io/webrtc-pc/#dfn-operations-queue) is a misnomer, as is the verb "enqueuing"—especially when the word "operation" is absent, which it always is:

> Return the result of [enqueuing](http://w3c.github.io/webrtc-pc/#enqueue-an-operation) the following steps to *connection*'s operation queue:

Critically, an *operation* is not a task. It is an *[asynchronous](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises) operation* that *begins* in a task, but *ends* in a later different task.

What `RTCPeerConnetion` implements is wholly a main-thread concept for serializing such operations. It is not a concept to get to main thread. It operates *only on* main thread.

Established terminology says such serialized asynchronous operations are *chained*, not queued, e.g. into *promise chains*:
```js
doSomething().then(doSomethingElse)
```

I'll add a PR to use the terms "chain" and "operations chain" instead.

> Return the result of [chaining](http://w3c.github.io/webrtc-pc/#enqueue-an-operation) the following steps to *connection*'s operations chain:


Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2227 using your GitHub account

Received on Friday, 12 July 2019 16:26:43 UTC