proposal for an 'appstart' protocol

[Bruno Haible]

The hyperlinks in text printed to terminal emulators [1] 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
    *.mp4 files).

(C) The action can be to send some information to a running application.
    Examples are:

      - 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
    command-line arguments.
    Examples are:

      - 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 (D), I would like to suggest a new protocol. The
purpose of standardizing this protocol is that different terminal
emulators behave the same way.

Specification
-------------

The name of the protocol should be 'appstart'.

The syntax of the URI is appstart://hostname/apptype/arg1/arg2...

When the hostname is equal to the machine's gethostname(), the
application should be started on that machine, without using network
protocols.

The apptype is an identifier. Apptypes get associated with actual
program names in an unspecified way.

The terminal emulator's action, when the user opens a hyperlink with
this protocol, is to start, on the designated host name, the application
that corresponds to this apptype, passing it the arguments (separated
by slashes in the URI).

It is recommended that starting such an application does not make
(possibly undesired) side effects.

Rationale
---------

Model (D) has a wide number of applications.

Use case (D) 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
be annoying. (Browser windows can be closed by JavaScript only if they
have been opened by JavaScript.)

Why an apptype? Why not directly include the application name in
the URI? Because the user may want to customize things:
  - Different text editors exist.
  - Different audio players exist.
  - Different PO file editors exist.
It is foreseeable that there will be both a system-level customization
(possibly through a text file in /etc, possibly through symbolic links
in /usr/bin) and a per-user customization (through a similar mechasnism
as for the association between MIME types and applications).

Why the recommendation regarding side effects? Because Koblinger's
gist [1] 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. If users want to open up the
start of applications to other machines (under their control), the
minimum security expectation is that starting an application remotely
is 1. limited to the set of applications registered for 'appstart',
2. will not be annoying.

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 [1], is implemented in
GNU 'ls', and works fine.

Note
----

The terminal emulator's action can be embodied in a program
that consults the apptype registry, similar to the way 'xdg-open'
considers the MIME type registry. This program should be called
'appstart-client'.
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 'appstart:', pass it to the
'appstart-client' program." Very simple.

Relation to (C)
---------------

It would in theory be possible to base the 'appstart' protocol on the
'appsocket' protocol. But this looks like overkill because it would
require a daemon running - consuming resources.

Relation to other protocols
---------------------------

The intended use case is not covered by any of the existing
specifications [2].


[1] https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
[2] https://www.freedesktop.org/wiki/Specifications/