In steps 19 - 23 of start a presentation [1] he intention of the spec (I believe) is that the following will happen in order:

1. P is resolved and the resolver function runs to completion.
2. The connectionavailable handler is invoked and runs to completion.
3. As part of the steps to establish a presentation connection [2], the connect handler is invoked or the error handler is invoked (and run to completion).

It occurs to me that since we haven't been explicit about the task sources for various asynchronous steps the browser takes (like establishing a presentation connection) this order is implicit. In our implementatation, a connection can complete in the background while step 20 is running for example.

Do we need to have stronger language in the spec around this @tidoust et al?

[1] https://w3c.github.io/presentation-api/#starting-a-presentation
[2] https://w3c.github.io/presentation-api/#dfn-establish-a-presentation-connection

Sorry I missed that issue somehow, @mfoltzgoogle.

I think it is a good idea to be explicit about the task source used. I would suggest the "networking task source" [1](used by browser navigation WebRTC, WebSockets), unless there is a good reason to create a specific task source or to use more than one?

Wording could be: "The task source for the tasks mentioned in this specification is the networking task source".

This would guarantee that the task queued to fire the connectionavailable event (i) runs before the task queued to fire the connect event (ii).

However, I note that what guarantees that (i) gets queued before (ii) is not the task source: the steps are run "in parallel" so are not tied to the event loop, but "in parallel" steps are still expected to run one after another:
http://www.w3.org/TR/html51/infrastructure.html#in-parallel

Also, Promise resolution is not tied to any task queue, but rather run as a microtask, I think (before next task is processed).

[1] http://w3c.github.io/html/webappapis.html#networking-task-source

Upon further thought, I note that I'm not clear whether it is a good practice to reuse the "networking task source" or to create a new one. Do you know?

Creating a new task source would give implementers more flexibility on how they assign priorities to the tasks the spec creates compared to tasks created by other specs, and would still give us what we need, meaning proper relative ordering of the tasks.

I'm investigating internally. This does not change the fact that the spec needs to be explicit about the task source that gets used.

As an implementer, the concept of a "task source" is an abstraction used to determine the order of callbacks in a fundamentally single-threaded renderer. Everything used to implement the API is going to run in a different process on various threads, and it's not clear how I would map a "task source" onto that execution model.

So I vote for whatever makes the spec clearest in terms of the behavior developers would see, versus what would match what implementers could or would do. Let me know what you find out. I'll keep the PR in the queue for now.

I went ahead and merged the PR. Among the task sources listed in HTML 5.2 the networking task source seems most appropriate (even if the the specific task is perhaps not necessarily network related).

If you have any further insight, then I can address it in a followup PR. Otherwise should we close this?

About re-using the networking task source or not, internal discussions suggest the answer is "it depends". I raised an issue against the TAG's Design Principles spec last week:
w3ctag/design-principles#38

Initial feedback from @annevk suggests using a dedicated task source. That matches my understanding. I don't think the task source used by the Presentation API is going to affect the behavior that developers might expect to see. It does not make any sense to mix calls to the Presentation API and to Web Sockets and expect a Presentation API event to fire before/after an event fired by Web Sockets.

As such, I would rather suggest to let implementers decide where they queue Presentation API tasks and create a "presentation task source" for the Presentation API.

As an implementer, the concept of a "task source" is an abstraction used to determine the order of callbacks in a fundamentally single-threaded renderer. Everything used to implement the API is going to run in a different process on various threads, and it's not clear how I would map a "task source" onto that execution model.

This is wrong. The threads are the "in parallel" steps (I think we should flush those out in more detail, but we don't really have the infrastructure defined for that yet). The event loop and its tasks are where JavaScript runs (e.g. a document or worker) and do in fact match what implementations are supposed to do there. So if that language does not match up somehow, there is a problem.

@tidoust Do you agree with the conclusion in w3ctag/design-principles#38 to create a dedicated task source? I'm happy to craft a pull request.

@mfoltzgoogle Yes, I think creating a dedicated task source is the way to go.