Development/Impress Remote Protocol

Version #1
Communication is over a UTF-8 encoded character stream (using  in the LibreOffice portion).

TCP
More TCP-specific details on setup and initial handshake to be written, but the actual message protocol is the same as for Bluetooth.

TCP port for a socket is.

Bluetooth
Bluetooth communication is over RFCOMM. For discovery use the "standard UUID for the Serial Port Profile" i.e. the 16-bit SerialPort UUID, or if necessary inserted into the Bluetooth BASE_UUID:. See https://www.bluetooth.org/Technical/AssignedNumbers/service_discovery.htm

Message format
A message consists of one or more lines. The first line is the message description, further lines can add any necessary data. An empty line concludes the message. I.e.  or.

You must keep reading a message until an empty line (i.e. double new-line) is reached to allow for future protocol extension.

Initialization
Once connected the server sends  (i.e.   is sent over the stream).

Subsequently the server will send either  if a slideshow is running, or   if no slideshow is running (see below for details of).

The current server implementation then proceeds to send all slide notes and previews to the client. This should be changed to prevent memory issues, and a preview request mechanism implemented.

Commands
Nested lists represent commands parameters.

Client → Server
The client should not assume that the state of the server has changed when a command has been sent. All changes will be signalled back to the client. This is to allow for cases such as multiple clients requesting different changes, etc.


 * 1) slide number
 * (resumes after a )
 * 1) slide number
 * (resumes after a )
 * (resumes after a )
 * (resumes after a )
 * (resumes after a )
 * (resumes after a )

Server → Client

 * (also transmitted if no slideshow running when started)
 * (also transmitted if a slideshow is running on startup)
 * 1) number of slides
 * 2) current slide number
 * 3) slide number
 * 4) the notes as a HTML document, and may also include   newlines, i.e. the client should keep reading until a blank line is reached
 * (slide on server has changed)
 * 1) current slide number
 * 2) slide number
 * 3) a Base64 encoded PNG image
 * 1) slide number
 * 2) a Base64 encoded PNG image

Client’s Workflow

 * 1) Connect to a server via socket.
 * 2) Send the message.
 * 3) If there will be the message from server   it is necessary to display PIN to a user so one can enter it at the server.
 * 4) Wait for the message from the server.
 * 5) Send commands and receive responses.

New features

 * Pointer.
 * Downloading presentation file.

Proposal by Artur Dryomov
A very simple request can be something like this. {   "action": "pair", "client": { "name": "Fancy Phone Model", "pin": 1234 } } Or like this. {   "action": "pointer", "coordinates": { "x": 100, "y": 200 } }
 * Add the protocol’s versioning to avoid compatibility issues.
 * A client should implement a single protocol version, the server should support all versions with deprecation of old versions after some time period.
 * The versioning should be implemented via handshakes because there are no URLs or whatever used by clients — just commands. The required protocol version can be requested by client so server will know how to operate with each client.
 * The first protocol version has no versioning so I suggest to use the first protocol version by default.
 * Remove sending all previews and notes to client after starting a slideshow to avoid possible huge memory usage on clients. Optimize commands and their responses.
 * Use serialization (JSON or XML — probably XML is better for LO infrastructure).