Define behavior when sending a message to a PresentationSession fails

[mfoltzgoogle]

The spec does not define the outcome when the UA is unable to send a message to a connected PresentationSession. As the spec includes a recommendation that the connection between sessions be treated as a reliable channel, it seems that we should notify the application when that guarantee cannot not be met.

Here are a few options (some are not mutually exclusive):

1. Add an error event to the PresentationSession to notify the application that there is a failure to deliver the message.
2. Close the PresentationSession (which fires the close event).
3. Add a return value to (or return a Promise from) send() to convey the outcome of the message delivery.
4. Queue the message and attempt redelivery in case the underlying channel becomes reconnected at a future time.

I am thinking a combination of 1 (to let the application know a message was not delivered in a timely manner) and 4 (so that transient failures of the channel don't require intervention by the page).

We may want to allow the page to also set a timeout for message delivery that would result in outcome 2.

[schien]

Agree with the proposal of combining 1 and 4. I remember this is the consensus during the previous f2f meeting.

[obeletski]

Webrtc is using combination of 1 and 2 in case of sending failure [1], since they were considering case when output buffer is full and nothing can be done. I agree that we should wait for reconnect to happen if that is possible, so it would be 1 + 4 + after timeout 2.

1. http://w3c.github.io/webrtc-pc/#dom-datachannel-send

[mounirlamouri]

I would be in favour of not automatically close and let the web page make that decision.

Regarding promise vs. event, I would prefer using a promise because it makes it clearer the error is about the message sending and it allows different error handling depending on the send() call. It also prevents us from having to pass back the message that was sent and all the issues with the type of the message. It comes with a bit `more overhead than the event though.

session.onsenderror = function(e) {
  // Note: e.message? e.data? what should we expect the type to be?
  console.error("Was not able to send message '" + e.message + "'");
};
session.send(msg);

vs

session.send(msg).catch(function(e) {
  console.error("Was not able to send message '" + msg + "'");  
});

If we go with the event, at least, I think we should not use error but senderror for the event name.

[schien]

Hi @obeletski, we can simply transit the session state to "disconnected" while underlying transport channel is lost. Application can later perform session resumption on this opened-but-disconnected session object and it'll be easier to define the algorithm about session resumption (i.e. cannot resume session that has been explicitly closed, either by application or browser).

The promise interface proposed by @mounirlamouri looks like the semantic of Stream API, which looks good to me.

[obeletski]

Makes sense, since we also agreed on adding "terminated" state in addition to "disconnected" in #35 (comment)

[mfoltzgoogle]

@mounirlamouri:

I would be in favour of not automatically close and let the web page make that decision.

We would need to add a means for the page to terminate its session (but not the underlying presentation), i.e. a PresentationSession.disconnect() method.

Regarding promise vs. event, I would prefer using a promise because it makes it clearer the error is about the message sending and it allows different error handling depending on the send() call.

This makes the code for sending multiple messages in sequence feel odd and less performant:

var s = theSession;
s.send("first-message").then(s.send("second-message"), disconnectSession(s)).then(

In this code, the second message can't be queued until delivery of the first message succeeds. This also means a separate event loop/task for each message in a sequence. Perhaps we could rewrite the send API to take sequences of messages? But would that negate the proposed advantage of having one Promise per message?

Or what would happen if:

session.send("first-message");
session.send("second-message");

Would these messages get sent if no resolver is provided?

---

Idea: as suggested, would an exception attached to send() be better than an error event? That way the caller knows which invocations of send() failed and we don't have to provide message details in the event.

[tidoust]

See relevant discussion at TPAC F2F:
http://www.w3.org/2015/10/28-webscreens-minutes.html#item03

RESOLUTION: For issue #149, adopt options 1. and 2. and define an error event that reports the message that could not be sent

[mfoltzgoogle]

PR #227 adds a PresentationConnectionCloseEvent which is fired when a connection is closed for any reason. It can take a reason value of "error" in cases where the presentation is disconnected for underlying platform reasons (network disconnection, etc.).

If there's an error sending a message through the underlying message transport, there's guidance to include a snippet of the offending message in the event's message property.