Subject: Protocol comments

From: Jim Davis <jrd>
Date: Wed, 21 Jan 87 12:41:23 EST

The proposed protocol extensions for DICTIONARY look good to me.
I have a few questions and suggestions:

1) I would suggest a different scheme for modes.  Instead of separate
commands for each mode, define a single new command, MODE, which takes one
required argument, the name of a mode, and one optional argument, a string
value for that mode.  For Boolean valued modes, the string YES and NO shall
be accepted.  The MODE command returns an error message if given an
unrecognized mode, an unacceptable value, or missing or extra args.

Then define a mode (or switch, if you prefer that term) FORMAT.  By default,
FORMAT is YES.  

The advantage of this plan are:
 1) it makes clear that RAW_MODE and FORMAT_MODE are mutually incompatible.

 2) It makes it easier to add new modes.

 3) it eliminates the "mode inquiry" command 

Perhaps there should also be the command MODES (no args) which returns
values of all modes.

2) I don't understand how FORMAT affects the PRONUNCIATION command.
Since PRONUNCIATION is new, there is no need for it to do formatting.
It *might* be helpful to have the server convert from the internal
Webster coding to ARPABET, but if it isn't going to do this it
may as well not do anything at all.

3) Would it be desirable and easy to allow the Client to specify the
kind of formatting done by the Server?  For example, you might want
to tell the Server the line length of the terminal, or whether 
some form of emthasis (bold, inverse, underline) was available as
the "man" program uses.  Or perhaps the X or other window system
provides methods of encoding font shifts...This is all pretty speculative,
and not very important to me at present, although it suggests
the value of an extensible protocol for setting modes (or switches)