Loop/Architecture/Data Channels: Difference between revisions
(Initial version of data channel document) |
(→Format of Data: Add info on the contentType) |
||
Line 21: | Line 21: | ||
Data sent across the data channel should be encoded in standard JSON format. Implementations should not fail if additional fields are sent within a message. | Data sent across the data channel should be encoded in standard JSON format. Implementations should not fail if additional fields are sent within a message. | ||
It is envisioned that all Loop messages for a data channel will have a contentType field specifying the type of message. Hence the message may be ignored if the contentType is not supported. ''It may be necessary in future to add a feature detection capability.'' | |||
Individual data types have their own structures. | Individual data types have their own structures. |
Revision as of 14:10, 24 August 2015
Rooms and Direct Calls in Loop contain the opportunity for text chat. Future extensions of Loop functionality include the possibility for sending mouse locations to the peer, and there are other extensions expected as well.
This document defines the structure for the data channel messaging.
Current Data Types
Loop currently supports transfer of:
- Text messages
Data Channel Names
The naming of a channel refers to the capability within WebRTC Data channels to supply a name for the channel. The Loop data is allocated to channels as follows:
- "text"
- Text messages
Format of Data
Data sent across the data channel should be encoded in standard JSON format. Implementations should not fail if additional fields are sent within a message.
It is envisioned that all Loop messages for a data channel will have a contentType field specifying the type of message. Hence the message may be ignored if the contentType is not supported. It may be necessary in future to add a feature detection capability.
Individual data types have their own structures.
Text Messages
{ contentType: "chat-text", message: "Hi!", sentTimestamp: "2015-08-24T14:00:27.834Z" }
- contentType: Fixed to "chat-text"
- message: A standard JavaScript string
- sentTimestamp: An ISO encoded date
Note: Implementations are expected to handle their own received timestamp, so that messages are displayed in the correct order e.g. in case of clock skew across the two machines.