All communication consists of messages that are one line of human-readable UTF-8 text (with no terminating newline), optionally followed by a single newline and arbitrary (potentially even binary) data. The WebSocket distinction between 'text' and 'binary' frames has no meaning for us for messages that don't contain additional binary data; such messages can be either 'binary' or 'text' from the WebSocket point of view even if we require them (the single line) to be UTF-8. In other words, an implementation is free to send such a single-line message as a WebSocket 'binary' frame, and the receiving implementation must treat that equally as if it was a 'text' frame. The WebSocket protocol says that 'text' frames are to be "interpreted" as UTF-8, so it is probably best to indeed use 'binary' frames for messages that contain optional non-UTF-8 data. The protocol is not a request-response one. Messages may be sent in either direction at any time, either in response to some message, or spontaneously. For 'tile' messages, the client may send a bunch of tile requests without waiting for return messages. The server may send tiles proactively (guessing what the client might need). Etc. The original intent was that the parameters of the messages can be in any order, as they are in a name=value form anyway and the name indicates which parameter is which. Sadly, this was not explicitly mentioned in this document, or tested by unit tests. So now we have code here and there that assumes that parameters are in a specific order anyway, thus losing the benefits of the named parameters. Oh well. When the document is password protected, it already implies that the document didn't load, and that with the proper password we should try again. Similarly for when the password given is wrong. However, if loading fails and it isn't a password-related failure, faileddocloading error is returned and in this case the client handles it as a final error (that requires reloading to retry). client -> server ================ canceltiles All outstanding tile messages from the client to the server are dropped and will not be handled, except tile messages with an id parameter. There is no guarantee of exactly which tile: messages might still be sent back to the client. tileprocessed tile= Previously sent tile (server -> client) arrived and processed by the client. Tileid has the next structure : :::: downloadas name= id= format= options= Exports the current document to the desired format and returns a download URL The id identifies the request on the client. id can take following values: * 'print': When request for download is basically for print purposes * 'slideshow': When request for download is for showing slideshow * 'export': Just a simple download getchildid Requests the child id so that it knows where the files needs to be sent when it is inserted in the document gettextselection mimetype= Request selection's content, which is returned via 'textselectioncontent', if the selection is text-only and relatively small. However, for selections containing images and other embedded objects, or if the selection is a large text blob, the response is 'complexselection'. paste mimetype= Paste content at the current cursor position. insertfile name= type= Inserts the file with the name into the document, we currently support: type = 'graphic': The file has been previously uploaded using insertfile POST type = 'graphicurl': The file is supposed to be downloaded by the core itself; it does so from the URL provided in 'name' selectbackground name= Inserts a graphic file with the name into the document as background. key type= char= key= is 'input' or 'up', and are numbers. load Deprecated. load [part=] url= [timestamp=