diff --git a/index.html b/index.html index ee9db06..e58a9b9 100644 --- a/index.html +++ b/index.html @@ -457,7 +457,6 @@
The restrictions being orientation agnostic means that they will automatically be adjusted to the orientation of the frame being @@ -466,6 +465,7 @@
This section extends {{RTCDataChannel}} by making it transferable.
-This allows sending and receiving messages outside the context the connection was created, for instance in workers or third-party iframes.
+This section extends {{RTCDataChannel}} by exposing it to any type of {{Worker}} (not just DedicatedWorker
).
The WebIDL changes are the following:
@@ -1301,58 +1300,6 @@partial interface RTCDataChannel { };
The create an RTCDataChannel algorithm is updated by adding the following steps after step 4 of the original algorithm:
-Initialize channel.`[[IsTransferable]]` to true
.
Queue a task to run the following step:
-Set channel.`[[IsTransferable]]` to false
.
This task needs to run before any task enqueued by the receiving messages on a data channel algorithm for channel. - This ensures that no message is lost during the transfer of a {{RTCDataChannel}}.
-Set channel.`[[IsTransferable]]` to false
.
The {{RTCDataChannel}} transfer steps, given value and dataHolder, are:
-If value.`[[IsTransferable]]` is false
, throw a "DataCloneError" DOMException.
Set dataHolder.`[[ReadyState]]` to value.`[[ReadyState]]`.
Set dataHolder.`[[DataChannelLabel]]` to value.`[[DataChannelLabel]]`.
Set dataHolder.`[[Ordered]]` to value.`[[Ordered]]`.
Set dataHolder.`[[MaxPacketLifeTime]]` to value..`[[MaxPacketLifeTime]]`
Set dataHolder.`[[MaxRetransmits]]` to value.`[[MaxRetransmits]]`.
Set dataHolder.`[[DataChannelProtocol]]` to value.`[[DataChannelProtocol]]`.
Set dataHolder.`[[Negotiated]]` to value.`[[Negotiated]]`.
Set dataHolder.`[[DataChannelId]]` to value.`[[DataChannelId]]`.
Set dataHolder.`[[underlyingDataTransport]]` to value underlying data transport.
Set value.`[[IsTransferable]]` to false
.
Set value.`[[ReadyState]]` to "closed".
The {{RTCDataChannel}} [=transfer-receiving steps=], given dataHolder and channel, are:
-Initialize channel.`[[ReadyState]]` to dataHolder.`[[ReadyState]]`.
Initialize channel.`[[DataChannelLabel]]` to dataHolder.`[[\DataChannelLabel]]`.
Initialize channel.`[[Ordered]]` to dataHolder.`[[Ordered]]`.
Initialize channel.`[[MaxPacketLifeTime]]` to dataHolder.`[[MaxPacketLifeTime]]`.
Initialize channel.`[[MaxRetransmits]]` to dataHolder.`[[MaxRetransmits]]`.
Initialize channel.`[[DataChannelProtocol]]` to dataHolder.`[[DataChannelProtocol]]`.
Initialize channel.`[[Negotiated]]` to dataHolder.`[[Negotiated]]`.
Initialize channel.`[[DataChannelId]]` to dataHolder.`[[DataChannelId]]`.
Initialize channel underlying data transport to dataHolder.`[[underlyingDataTransport]]`.
The above steps do not need to transfer `[[BufferedAmount]]` as its value will always be equal to 0
.
- The reason is an {{RTCDataChannel}} can be transferred only if its send() algorithm was not called prior the transfer.
If the underlying data transport is closed at the time of the [=transfer-receiving steps=], - the {{RTCDataChannel}} object will be closed by running the announcing a data channel as closed algorithm immediately after the [=transfer-receiving steps=].
-