Character By Character (CBC) Mode Notes

A flag in the NODEIDX stores the node's current chat mode, 0 for old-style LBL
chat, 1 for Dual Window chat mode, and 2 for Split-Screen CBC mode.  The
messaging routines use this value to determine how to send the text.

CBC text is stored in a new series of temp files called CHR#####.TCH where
##### is the node number.  The first byte of this file is used simply for
locking, and does not contain any particular information.  All subsequent bytes
contain the text typed up until this point, as typed by the user.

Actions and other such messages are translated as normal and the text is dumped
to this file.  Commands and actions will be prefixed with a configurable
special character (defaults are probably / for commands, which is already used
for many commands, and . for actions, which is common in Major) so TOP knows
not to echo them to the other users.

The CHR chat file is opened in Binary Append mode for fastest file i/o.  The
first byte is to be locked when the file is in use.  An time-delayed output
buffer will be necessary for smoother operation, based on the performance of
the prototype Private Chat code.  It looks like the best thing to do is to
flush the buffer at configurable intervals, probably 1/3 or 1/2 a second by
default.  It also will probably be helpful to only read the buffer at
configurable intervals, defaulting at 1/5 or 1/4 a second.

Once the receiving node reads the file, the size is changed with chsize() to a
size of 1 byte, the file pointer is reset (using SEEK_END), and the first byte
is of course then unlocked.  This allows an added speed advantage by allowing
receiving nodes to simply check filelength <= 1 to know whether or not new text
has arrived.  Both reads and writes are to be preformed at seperate
configurable intervals.  The reads configured by time, and the writes
configured by time but also prematurely performed after reads, whichever event
comes first. This should allow for a smooth flow without bogging down the
system too much.

ADDENDUM

The CHR*.TCH files will need to contain sending info instead of just text
bytes.  The best way is to provide a three byte header for each write to the
file as follows:

 Bytes 0,1 - Sending node.
    Byte 2 - Length of text for this dump.

    The text bytes follow for the length given in byte 2.  A fourth byte may be
added to the header if special info. flags are needed, but this will not cause
any backward compatibility problems so it has been left out for now.

    Another option would be to assign 256 byte buffer zones for each of the 6
nodes in the file.  This would cause less file sharing conflicts but it would
result in more file accesses, although it would also be faster on screen
because TOP can read one node at a time and not have to jump around to each of
the different windows so much.