camilla(1) - Reflections

Camilla, when invoked, attempts to emulate the standard geek(5) interface, as well as a reasonable subset of the protocols in the human(5) and female(5) families.

The following options are available:

-f	Force the usage of NVC(4) (Non-Verbal Communication) I/O for exchanging state information and acknowledgements. This feature is still highly experimental and is not recommended for production environments. Use with care.
-n days	Do not actually invoke camilla; instead give advance notice of an upcoming invocation days number of days from now. When used as expected, and with a value of 2 or more, this greatly improves the stability of the upcoming session.
-r subject	Select rant mode. All incoming information will be ignored, and all outbound information will be centered around the current, internally chosen subject. The value of subject, specifying the desired subject, is ignored.
-s state	Change the initial expected state of the session. This greatly improves performance, as it allows the bypassing of environment analysis. Hinting states such as Mournful and Apologetic gives an especially high performance boost. The default state is Curiously-Neutral.
-v	Verbose output. (Equivalent to -r Default)

The following environment variables affect the execution of camilla:

COMPUTER	When set in the environment, it may act as a severe distraction and may significantly impair normal communication with camilla.
NOISE	If the environment contains NOISE, camilla may either not start, or may run with a significantly reduced feature-set. Additionally, when set to ``loud'' or ``sudden'', attempted communication may be ignored, or lead to immediate session termination.
PEOPLE	If set to a value greater than 1, expect noticeably longer delays between responses.
SMOKE	If the environment contains SMOKE, camilla will leave(1) immediately, regardless of the job's current priority.

Camilla is written for libautie(3), which lacks support for NVC(4) (Non-Verbal Communication) I/O. As such, the default mode is to send state information and acknowledgements to the regular output stream, and also to expect other programs to pass their out-of-band data in the same way. Every effort is made to ensure that this information is properly encoded, according to established standards. However, as most other programs do not expect to receive such data in this way, important information is often lost. You may need to consult the documentation for your particular software for help on alerting it to this peculiarity.

Considerable efforts have been made to adapt camilla to using NVC(4) I/O in a compatible way. This mode of operation is still unstable, however, and may cause your session to crash, or enter a feedback loop (see BUGS). You have been warned.

The Implied, Deceitful and Tactful encodings are not supported, nor are there any plans to support these in the future. Limited support exists for detecting these encodings in incoming data, and upon detection, an attempt will be made at negotiating a compatible encoding. Note that many programs still do not support such negotiation.

When not invoked with -f or -s, a state of Curiously-Neutral is written continuously to the NVC(4) output stream. This may cause serious malfunction in programs that are hard coded to listen for acknowledgements via this interface. The currently recommended solution is to not use these programs together if it can possibly be avoided.

Frequent invocation of camilla for communication with software written for libNT(3) will cause camilla to sleep(2) with increasingly longer durations between invocations. Attempts at forcing early termination of these sleep intervals may be successful in the short run. However, eventually camilla will respond by re-connecting its output stream to its own input stream, causing a self-controllable feedback loop and thus preventing a crash. This naturally terminates all current communication, and as such, the practice should be avoided.

If more than one process not based on libautie(3) attempts to communicate with camilla at any given time, it will revert to a hard coded list of predefined responses. This is done primarily for performance reasons, as due to threading issues, the response times would otherwise become unreasonably slow.