proposal for an 'appsocket' protocol
bruno at clisp.org
Mon Jan 6 21:43:52 UTC 2020
The hyperlinks in text printed to terminal emulators  can have a
wide range of applications. When the user selects to open the hyperlink,
the following types of actions are practically useful:
(A) The action can be to open a browser window. This is supported through
the 'http' and 'https' protocols.
(B) The action can be to open a file, in whatever application is customary
for the type of file. This is supported through the 'file' protocol.
Typically, the program will be chosen based on the suffix of the
file name (e.g. a text editor for *.c files, a video viewer for
(C) The action can be to send some information to a running application.
- An interactive program has a 'help' command that prints
a set of available commands. When the user selects one of these
command, the command gets added to the prompt. This reduces
the amount of necessary typing.
- A Lisp system prints some objects, in normal Lisp syntax
(often in abbreviated form: #(a b c ...) or #<OBJECT XY>)
with hyperlinks that identify the object. When the user selects
such a hyperlink. the Lisp system opens an "inspector" that
shows details of the object.
(D) The action can be to open an application with a specific set of
- The 'grep' program shows references into disk files. When the
user selects one of these references, a text editor opens the
referenced file at the particular line.
- A program presents the table of contents of an audio CD.
When the user selects one of the items, the audio player is
launched, and it starts playing the audio file at the particular
time within the file.
- Any program that produces localized messages: When the user
selects one of the localized messages in the terminal output,
a PO file editor opens, at the point where the translation
of the particular message is defined, and the user can correct
the translation and save the modified PO file.
For the use case (C), I would like to suggest a new protocol. The
purpose of standardizing this protocol is that different terminal
emulators behave the same way.
The name of the protocol should be 'appsocket'.
The syntax of the URI is appsocket://hostname:port/payload .
When the hostname is equal to the machine's gethostname(), the
connection should be done to localhost.
The port is in the range 1..65534.
The payload is defined by the application.
It is recommended that slashes are used to separate different parts
of the payload.
It is recommended that one part of the payload is a nonce token ,
for security reasons.
The terminal emulator's action, when the user opens a hyperlink with
this protocol, is to open a TCP/IP client socket to the given host name
and port and send the "/payload" string (including the starting
slash), followed by a newline, to that socket, then finally close
the client socket.
Experience with GNU poke  has shown that the model (C) provides very
satisfying user interactions.
Use case (C) cannot be based on (B), because if the action would be
to open a browser window that triggers some secondary action, the user
would be required to manually close this browser window, which would
Why a socket? Because Koblinger's gist  considers the possibility
to use hyperlinks through ssh, that is, have the terminal emulator
run on a different machine than the program that emits the hyperlink.
A TCP/IP socket is the easiest way to enable such communication
Why the special convention regarding the machine's gethostname()?
Because in the frequent case that the terminal emulator and the program
run on the same machine, it avoids making DNS related queries. This not
only saves elapsed time, it also makes the communication independent
of the contents of the /etc/hosts and /etc/resolv.conf files. This
convention already exists for 'file' URLs in , is implemented in
GNU 'ls', and works fine.
The terminal emulator's action can easily be embodied in a program,
which I've called 'appsocket-client' (attached). A terminal emulator
can simply invoke this program, passing it the URI on standard input.
This way, the protocol logic does not need to be hardwired into
any terminal emulator. The only logic a terminal emulator needs to
contains is: "If the URI starts with 'appsocket:', pass it to the
'appsocket-client' program." Very simple.
Relation to (D)
It would in theory be possible to base the 'appsocket' protocol on the
'appstart' protocol. But this looks like overkill because
- it would be sensitive to user customization, where no user
customization is needed nor useful,
- it would require two successive program invocations instead of one,
at each interaction - making things slower.
Relation to other protocols
The intended use case is not covered by any of the existing
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4838 bytes
Desc: not available
More information about the xdg