Interprocess communication through Hipe

Like many display servers, Hipe provides some capabilities for sending data from one application to another via the display server itself. While the operating system provides its own capabilities for this, transmitting data through the display server is sometimes useful in its own right: for example, where the user must be involved in selecting target application for data to be exported to (e.g. by selecting the target application from a menu in the desktop environment itself), or where the on-screen relationship between two applications is significant.

Basic message passing

The HIPE_OP_MESSAGE instruction is used to send an arbitrary message to a direct child or parent frame within Hipe.Both applications must have a mutual understanding of what these messages mean, so this technique is most useful in cases where the parent application manages child frames that are directly related to it. For example, a suite of utilities that are all written by the same author and are designed to exchange messages with one another.

FIFOs

A FIFO (or named pipe) is a capability of the operating system where a virtual 'file' is written to by one applicaiton and read from by a different application. The resource looks and behaves like a file on the disk, but no data is actually written to the disk. In certain cases, an actual file on the disk may be used.

Examples include sending a file from a word processor application to a printer application, saving a file to a cloud application by writing to a FIFO that is then read by the cloud access utility, and even simply loading a file by requesting the file's contents from a file manager utility.

Hipe does not create or maintain FIFO resources itself but does provide a set of instructions for allowing applications in Hipe to negotiate setting them up and exchange of data.

• HIPE_OP_FIFO_ADD_ABILITY: A client application can issue this instruction to notify the parent frame of a capability that it has. For example, the ability to save a file to a certain hardware device. The parent frame (e.g. a framing manager) can then choose to maintian a menu of capablities for the user to choose from when choosing to export or import data into another child frame. Note: a framing manager that does not support the use of FIFOs can simply ignore such instructions.
• HIPE_OP_FIFO_REMOVE_ABILITY: A client application can issue this instruction to withdraw a capability that is no longer offered. The parent frame receives the instruction and should remove the ability from its own list accordingly. A client is not guaranteed to remove all its abilities before it terminates, so whenever a child frame terminates, a supporting framing manger should also discard related abilities from its own list.
• HIPE_OP_FIFO_GET_PEER: When a client application requires another application to exchange data with, it sends this instruction to the parent frame (framing manager). A supporting framing manager should then prompt the user to select a peer action from a menu (based on abilities that have been advertised by other applications), relay the instruction to the chosen application, and allow the chosen application to prompt the user for further details and then either ACCEPT or REJECT the connection - which will notify the originator of the FIFO to open and read/write to.
• HIPE_OP_FIFO_RESPONSE: After receiving a ...GET_PEER instruction, a chosen application may prompt the user for more details about the required operation (e.g. if the advertised ability was printing, how many pages does the user want to print? If the chosen action was saving a file, the user may be prompted for a filename and location), before either accepting or rejecting the peer application. A HIPE_OP_FIFO_RESPONSE message will be sent by the chosen application to the framing manager, which then relays it to the peer application, to signal that the FIFO has been established.
  If the chosen application cannot fulfil the request, or the user selects a cancel option in the chosen application, the chosen application relays a 'reject' message back to the peer to indicate that the operation has been cancelled and that the user is already aware of it.
• HIPE_OP_FIFO_OPEN: The client application sends an ..._OPEN instruction to notify the host peer that it is opening the FIFO in a particular access mode. Since a FIFO can work in either direction after creation, it is important that both peers know what the other application requires: for example, if the client is opening the resource to read, the host should open the same FIFO for writing, and begin streaming the required data.
• HIPE_OP_FIFO_CLOSE: The client application sends a ..._CLOSE instruction to notify the host peer that it has closed the FIFO resource at its end. This does not mean the FIFO will not be used again, but will be reopened in an appropriate access mode when it is next required (e.g. open for reading to load a file, then later reopen for writing to save changes to that file).
• HIPE_OP_FIFO_INFO: Properties of a relationship, such as the name of the ability the user chose and the title of the application at the other end, so an application can tell the user why a file is in use. The framing manager's properties are kept apart from what the other application says about itself.
• HIPE_OP_FIFO_DROP_PEER: At the conclusion of a FIFO relationship between two peers, either application issues this instruction, which is relayed to the other application, to signal that the FIFO resource has been (or should be) destroyed.

A typical interaction might go like this:

1. An application (the 'host') uses HIPE_OP_FIFO_ADD_ABILITY to tell the framing manager about an ability it offers (such as open, save, print, scan, edit, etc.)
2. In another application (the 'client'), the user selects an option to import or export data from/to another application, and the application sends a HIPE_OP_FIFO_GET_PEER request to the framing manager with details of the read/write access it requires.
3. The framing manager prompts the user to select a host application and switches focus to the host to allow the user to select options. The framing manager relays the HIPE_OP_FIFO_GET_PEER instruction to the chosen host application and also inserts the name of the ability the user has selected.
4. The host sends a HIPE_OP_FIFO_RESPONSE response to inform the client of the resource path, and access permissions that are available.
5. The client and host exchange HIPE_OP_FIFO_OPEN instructions to coordinate opening the FIFO resource at both ends in the required direction of transfer.
6. The client sends a HIPE_OP_FIFO_CLOSE instruction when it has finished reading or writing the data required. The host repeats this message back to the client to acknowledge that the resource is now closed at both ends.
7. The client may re-open the FIFO any number of times (e.g. to save the latest changes to a file while the user is working on it). The host is informed each time, so that the service can be provided at the other end.
8. When the client is done with the peer connection, it issues a HIPE_OP_FIFO_DROP_PEER instruction to tell the host to discard the FIFO resource.
9. Before the host terminates, it issues a HIPE_OP_FIFO_REMOVE_ABILITY instruction to indicate that it is no longer offering the FIFO service.

If the host should be the one that starts transfers (for example, a file manager hands a file to an editor, and the editor saves its changes back), the two applications can agree to swap roles once, before the first transfer: the client asks for the s access mode, the host grants it, and the client then sends HIPE_OP_FIFO_OPEN with mode s. From then on the editor is the client and the file manager serves it. The FIFO itself is still created and removed by the application that answered the HIPE_OP_FIFO_GET_PEER. See "Swapping roles" under HIPE_OP_FIFO_OPEN.