Executables
mark
mark is intended to be the primary command line interface for client interactions with mKTL. It doesn’t exist yet, but when it does, the command set is expected to be something akin to:
mark get key1 key2 key3
mark plot key1 key2 key3
mark set key1=foo key2=bar key3=baz
markd
The markd executable provides a command-line interface to invoke a
persistent daemon executing a Store
subclass to implement its core
functionality. The markd executable is positioned to be the common point
of entry for any Python-based mKTL daemon.
The command line arguments describe the intended usage:
usage: markd [-h] [-m MODULE] [-s SUBCLASS] [-c CONFIGURATION] [-a APPCONFIG]
store identifier
This is a generic mKTL daemon. The real work is done in the subclass of
Daemon.Store (if any); this executable parses command-line flags, invokes
a Daemon.Store instance to handle any/all requests, and otherwise waits
until the program is terminated.
The store name and configuration identifier must be specified in order
for this daemon to function correctly; all other arguments are optional.
positional arguments:
store Name of this mKTL store.
identifier Unique identifier for the mKTL configuration
associated with this specific daemon; this is an
arbitrary string, and must be unique for this daemon
within this store.
options:
-h, --help show this help message and exit
-m, --module MODULE Module to import which contains the Daemon.Store
subclass to invoke.
-s, --subclass SUBCLASS
Specific Daemon.Store subclass to invoke; this is the
bare class name (Store), not a fully qualified class
name (mKTL.Daemon.Store).
-c, --configuration CONFIGURATION
File containing daemon-specific mKTL configuration of
items; if specified, the contents of this file will
supplant any cached daemon-specific configuration for
this identifier.
-a, --appconfig APPCONFIG
Custom configuration file location, not used directly
by mKTL, but made available to the Daemon.Store
subclass. How this directive is used is entirely up to
the application-specific subclass code.
For example, to run markd for the store 'rosebud', using the existing
on-disk configuration identified as 'innocence', first using the default
caching implementation, and then with a custom Kane.Sled subclass of
Daemon.Store, one might invoke:
markd rosebud innocence
markd rosebud innocence --module Kane --subclass Sled
markguided
The markguided persistent daemon is a discovery aid, listening for UDP broadcasts on a well-known port number so that clients can be directed to a specific mKTL daemon handling requests for a specific store, or fraction of a store. While having a markguided daemon running is not a strict requirement it is a key component of automated discovery of mKTL stores on a local network.