The problem with FTP is that the client MUST select the
correct mode (Ascii or Image) wheras the server (presumably)
knows what the format is. The client guesses the content-type
from the file suffix. It now also guesses the encoding
as well. It will therefore select A for .txt files and I
for .Z files, and so get the right results even with
Macs and non-ASCII servers around. The suffix table
can be set up in the client's rule file, if it is used with
one.
The executable scripts problem I viewed as another format
negotiation problem. It is easier to set up the suffix table
and the command you want executed for given content types.
Its all in the rule file. If you are rash enough to put in
presentation application/x-csh "csh %s"
into your client rule file, then you can try out the
example script in the test data linked to the
test page ...
http://www3.cern.ch/hypertext/WWW/Test/Executable/test1.execme.csh
if I remember rightly.
Obviously this is just a hook. A script which previews it or
at least asks would be more reasonable.
I used application/x-csh rather than inventing exec/x-csh as I
think this is more in the MIME spirit.
The competition is obviously on for portable
1. safe scripting language for general use
2. timed presentation language (HyTime based?) for
illustrated talks which give themselves.
I seem to have got off the topic of the release...
Other things...
Of course I would expect X clients to load rules from the
Xresource database too -- by calling HTSetConfiguration().
Similarly other platform-specific sources of initilisation
information.
Tim BL
CERN