Thread with some poorly put together thoughts.
-
Finite: All inputs to a program are finite. In every mainstream OS, arguments are a string of limited size. They are not streams. We embrace this limitation.
-
Not shared: Processes also do not (normally) share memory, we embrace this limitation. You can pass a file name, but not an FD to that file. You cannot pass a pointer to memory, shared or otherwise.
-
Format: The format of arguments is determined entirely by the process. We impose no further format restrictions (e.g. JSON), and only suggest some basic schema types.
The main goal of the schema file is to describe correct arguments to the process, aid in editor/shell completion, and type checking, and it will not describe any argument combination which is incorrect.
The format of the schema file is JSON. JSON is chosen for its ubiquity, relative terseness with comparison to XML, and current popularity.
High-level overview:
- The schema describes a logical tree, listing combinations and alternatives of inputs.
- Each input is either an argument (presented as-is), an option (a
key-value combination such as
--sleep
and2s
), or a flag (which is on or off, such as--enable-debug
). - The schema contains a SHA256 which refers to the binary program it is describing. This avoids mistakenly using the wrong schema for a program.
Example file:
{
"version": "1",
"program-hash": "7392d580e09b22d66f687667d0a37fdec6611bfbb1e2e125e2f25778beeee201",
"inputs":
[
{ "type": "argument",
"name": "command",
"format": "string"
, "choices": ["plan","execute"]
},
{ "type": "option",
"name": "verbosity",
"format": "integer"
, "choices": ["0","1","2"]
},
{ "type": "flag",
"name": "dry-run"
}
]
}
The name of the program is re-used and suffixed with .schema
. This
is either colocated in the same directory as the binary (likely with
the same permissions), or else put in a directory of other schemas,
for example:
git
git.schema
ls
ls.schema
Or decoupled:
/usr/bin/git
/usr/bin/schema/git.schema