Development/Impress Remote Protocol

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

• Wiki Home
• Development
• Design
• QA
• Events
• Documentation
• Website
• Localization
• Accessibility
• Marketing
• Diversity
• Wiki Help

• Overview
• Reporting Bugs
• How to build
• Code Overview
• Git Commands
• Debugging
• EasyHacks
• Release Plan
• FAQ
• Developers
• Extensions
• → Open Issues

This page (may) contain content that is old and/or out of date. If you have experience in this area, please review this page for accuracy. Reason: WARNING: this page contains outdated information. For the latest documentation on the Impress Remote procotol please check sd/IMPRESS_REMOTE in the source tree. (https://cgit.freedesktop.org/libreoffice/core/tree/sd/README_REMOTE)

Version #1

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

Connection

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 1599.

Bluetooth

Bluetooth communication is over RFCOMM. For discovery use the "standard UUID for the Serial Port Profile" i.e. the 16-bit SerialPort UUID 0x1101, or if necessary inserted into the Bluetooth BASE_UUID: 00001101-0000-1000-8000-00805F9B34FB. 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. MESSAGE\n\n or MESSAGE\nDATA\nDATA2...\n\n.

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 LO_SERVER_SERVER_PAIRED (i.e. LO_SERVER_SERVER_PAIRED\n\n is sent over the stream).

Subsequently the server will send either slideshow_started if a slideshow is running, or slideshow_finished 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.

• transition_next
• transition_previous
• goto_slide

1. slide number

• presentation_start
• presentation_stop
• presentation_blank_screen
• presentation_resume (resumes after a presentation_blank_screen)

Server → Client

• slideshow_finished (also transmitted if no slideshow running when started)
• slideshow_started (also transmitted if a slideshow is running on startup)

1. number of slides
2. current slide number

• slide_notes

1. slide number
2. the notes as a HTML document, and may also include \n newlines, i.e. the client should keep reading until a blank line is reached

• slide_updated (slide on server has changed)

1. current slide number

• slide_preview

1. slide number
2. a Base64 encoded PNG image

Client’s Workflow

1. Connect to a server via socket.
2. Send the message LO_SERVER_CLIENT_PAIR\nCLIENT_NAME_DISPLAYED_AT_LIBREOFFICE\nYOUR_GENERATED_PIN\n\n.
3. If there will be the message from server LO_SERVER_VALIDATING_PIN\n\n 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 LO_SERVER_PAIRED\n\n.
5. Send commands and receive responses.

Version #2

New features

• Pointer.
• Downloading presentation file.

Proposals

Proposal by Artur Dryomov

• 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).

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
   }
 }