4.1. Devices

A 'device' is an object representing an actual input, output, or execution stream such as a disk file. Devices are simple objects which read, write, or execute data without parsing or interpretation. Instead, they interface to actual system device objects such as disk files, remote files, or text stored in memory. In Interscript parlance, an input device is called a 'source', an output device is called a _sink_, and a device which acts first as sink, and subsequently sources data that was sunk into it, is called a 'store'.

The input to interscript is represented by a source driver object. Both the tanglers and weavers write output via sink driver objects.

Currently implemented sources:

named_file_source: The most commonly used source driver reads a disk file named by a native filename.
ftp_file_source: This device initially reads files from an FTP host and creates a local copy. The local copy is read until it is deemed too old, at which point it is fetched again by FTP.
http_file_source: This device initially reads files from an HTTP host and creates a local copy. The local copy is read until it is deemed too old, at which point it is fetched again by HTTP.
url_file_source: Reads a file given a URL. Currently, ftp, http, gopher, and local files are supported. There is no caching.
stdin_source: Reads a file from standard input.
null_sink: Throws away data.
simple_named_file_sink: Writes a disk file given a native filename.
named_file_sink: This device writes a temporary disk file, and copies it to a nominated file if the two differ, both to prevent touching unchanged files, and to ensure the previous file is available during parsing, allowing generated files to be included back into the document.
stdout_sink: Writes to standard output.
memory: Writes and reads from memory.
disk: Writes and reads to disk (with separate read and write heads).

Under development are patch readers and writers. A patch writer compares two files, and, instead of replacing the old file with the new one if they differ, writes a patch file instead. The corresponding reader applies the patches to a copy of the old file and reads that instead. This mechanism provides rudimentary version control, allows stable files to be write protected, and permits posting and using patches by email or news.

Writers for news and email are also in the works. The email sink device is particularly useful to allow automatic regular updates (run as chron jobs) to send advice to the client.

The URL reader currently doesn't use a cache, because it uses the standard Python function 'urlopen', which doesn't use a cache. Hopefully this function will be upgraded to check expiration headers on http servers, and cache files locally.

A 'tee' writer --- a device which writes to several other devices -- is planned.
4.1.1. File names