libreoffice-online/loolwsd/protocol.txt
Tor Lillqvist 058416b9d7 Handle arbitrarily large tile: messages from child to parent
The parent currently uses a fixed-size 100000 byte buffer to receive
messages. Even with a tile size of 256x256 pixels, that is not enough for some
tiles that compress badly as PNG. Add a nextmessage: message that gives the
size of the immediately following message. Send a such before each tile:
message, and handle it appropriately. The nextmessage: message is used only
from child to parent process, it is never sent to the Websocket client.

Once Poco 1.6.1 is released, this will not be necessary.
2015-05-18 11:24:32 +03:00

104 lines
3.2 KiB
Text

All communication consists of messages that are one line of
human-readable UTF-8 text optionally followed by a single newline and
binary 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.
client -> server
================
load <pathname>
Deprecated.
load url=<url>
status
tile part=<partNumber> width=<width> height=<height> tileposx=<xpos> tileposy=<ypos> tilewidth=<tileWidth> tileheight=<tileHeight>
All parameters are numbers.
key type=<type> char=<charcode> key=<keycode>
<type> is 'input' or 'up', <charcode> and <keycode> are numbers.
mouse type=<type> x=<x> y=<y> count=<count>
<type> is 'buttondown', 'buttonup' or 'move', others are numbers.
uno <command>
<command> is a line of text.
selecttext type=<type> x=<x> y=<y>
<type> is 'start', 'end' or 'reset', <x> and <y> are numbers.
selectgraphic type=<type> x=<x> y=<y>
<type> is 'start' or 'end' <x> and <y> are numbers.
resetselection
saveas url=<url> format=<format> options=<options>
<url> is a URL, encoded. <format> is also URL-encoded, i.e. spaces as %20
options are the whole rest of the line, not URL-encoded, and can be empty
server -> client
================
error: cmd=<command> kind=<kind>
<freeErrorText>
<command> is the command part of the corresponding client->server
message that caused the error. <kind> is some single-word
classification
status: type=<typeName> parts=<numberOfParts> current=<currentPartNumber> width=<width> height=<height>
<typeName> is 'text, 'spreadsheet', 'presentation', 'drawing' or 'other. Others are numbers.
tile: part=<partNumber> width=<width> height=<height> tileposx=<xpos> tileposy=<ypos> tilewidth=<tileWidth> tileheight=<tileHeight>
<binaryPngImage>
The parameters from the corresponding 'tile' command.
Each LOK_CALLBACK_FOO_BAR callback causes a corresponding message to
the client, consisting of the FOO_BAR part in lowercase, without
underscore, followed by a colon, space and the callback payload. For
instance:
invalidatetiles: <payload>
invalidatecursor:
The communication between the parent process (the one keeping open the
Websocket connections to the clients) and a child process (handling
one document through LibreOfficeKit) uses the same protocol, with
the following additions and changes:
child -> parent
===============
child <id>
Must be the first message sent from the child to the parent. The
parent has passed the id (a 64-bit random number) to the child when
starting it, so this is how the child identificates itself.
nextmessage: size=<upperlimit>
each tile: message sent from the child to the parent is preceded by a
nextmessage: message that gives an upper limit on the size of the
tile: message that will follow. (We assume it is only tile: messages
that can be "large".) Once we depend on Poco 1.6.1, where one doesn't
need to use a pre-allocated buffer when receiving WebSocket messages,
this will go away.