__  ___
                               |_)( |_)
                               |  _)| \
                           S O F T W A R E
______________________________________________________________________

   Presents: Request Handler
Description: Processes netmails and sends appropriate text file back.
Requirement: Registered copy of Spot
    Version: 2.0
       Date: 19/01/94

      Status: Freeware.   
Contribution: n/a

 Acknowledge: Spot, Nico Francois; Arexx, William S. Hawes
______________________________________________________________________

               "There's an old Mechanoid saying..."

Brief ________________________________________________________________

Request Handler allows you to set up files to be sent when people
send a netmail to a specific name with a list of files they want.
It can currently only handle text files, but UUencoded files are
okay as long as they are pre-encoded, I hope to make a version
where this is not necessary.

FEATURES
ŻŻŻŻŻŻŻŻ
o Can be setup for more than one netmail area.
o Can be used with multiple files.
o Origin, name they send message to, and name sent on reply are
  customizable.
o Subject line customizable for individual files.
o Unread flag cleared on messages where a message has been
  written back, ie. the request has been sucessful.
o Unread flag not cleared on messages with 'UNREAD' in the
  subject line.
o Now works.

o Now allows Dos or Arexx scripts/commands to be issued remotely.

Usage ________________________________________________________________

INSTALLING REQUEST
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
The script can be copied to where you keep all of your Spot scripts
(usually REXX:, although mine are kept in Rexx:Spot).  The script can
be run from the option 'Execute Script' from the 'Arexx' menu or else,
and this is a better option, it can be installed directly to the Arexx
menu.  To do this, see the Spot documentation.

SETTING UP REQUEST
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Due to the lack of a prefs editor (one planned), it's a li'll bit
fiddly setting up, although nothing too bad.  In order to use
Request.spot you'll need a prefs file which is stored in ENVARC:.
  Create the file "Request.prefs" in ENVARC:, or copy the example
prefs file there and edit it to your suiting.
  The first line in the prefs file must be (no blank lines before)
"Request Handler (19.01.94)" otherwise you'll be told the prefs
file isn't compatible.  

Now, the order of the next lines makes no difference (I've finally
worked out why Niço used this method, it saves a hellova lot of
time and makes the prefs file a lot easier to read).

 TONAME=

This is the name the messages will need to be sent to by people
requesting.  It can be anything you like but I'd advise against
setting it the same as your name or all of your netmail messages
will be checked, which I must admit, isn't fast.

 FROMNAME=

In the same way, this sets the name that request will be sent by.
This you could set to your name but to save confusion at the other
end, it can be set the same as the to name.

 ORIGIN=

This line makes little difference in netmail areas, but is useful
if you are lucky enough to be able to run the request handler in
a local message area.  This will be used as the origin of the
request replies.

 AREA=

There may be as many of these as you like (and memory permits).
Follow it with the NET NAME of the area you would like checked.
Get permission before using in echoes.

 AREA=NET_2_254_149_3
 AREA=NET_1_234_567_8

 ENTRY=

These lines (any number), determine the requests themselves.
They should be entered in this format:

 TEXT,Name,File,Subject Line
 DOS,Name,File

TEXT means that the request of name 'Name' will look for an
ascii file called 'File' and send it to the requester
with the message subject line set to 'Subject Line'.
  For example: if the entry is as follows:

 TEXT,Req,T:Request.spot,This is Request

Then the requester must send a request with the word 'Req'
alone on a line somewhere in the body text.  Advist requesters
against adding huge amounts of text as this slows the process
down considerably.
  DOS entries work the same except the requester will not
receive any confirmation.
  Avoide using commas as these determine the where each
piece of data starts and ends.

USING REQUEST
ŻŻŻŻŻŻŻŻŻŻŻŻŻ
Using is the simplest.  Simply call the program straight after
importation as it will only check unread mail.  The unread
flag will not be affected.  _Import.spot can be editted to auto
check after import by creating a script such as:

 /* Auto check */
 Address Spot
 'Import CLOSEWIN'
 'Rexx:Spot/Request.spot'

EXTERNAL USAGE
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Outsiders can request files by sending a message so that it
will end up in one of the areas you specified in the prefs file ie.
by sending the message via netmail usually.  The 'to' line must be
set to the TONAME specified in the prefs file otherwise the
message will be ignored.  The magic file names should be placed
in the body text, one per line, alone:

 Request
 Welcome
 MyFile

  If the user wishes to add extra text to the message they can do
so providing that the lines do not start with magic filenames.
Perhaps all names should be prefixed with a symbol to prevent this
ie. *, this can be done easily by prefixing the names in the prefs
file. eg.

 TEXT,*Request,Dh1:Request.spot,Voila

  If the user wants to make sure that the text is read, they
can set the subject line to UNREAD which means the message will
remain unread even after being processed.  The word 'unread'
may appear anywhere on the subject line.

Future Enhancements __________________________________________________

o Clear Unreplied flag.
o Allow files to be UUEncoded by the script.
o Somehow allow Arexx commands to be run.
o Have some sort of monitoring, log files perhaps.
o Ignore text after the tearline.

Disclaimer ___________________________________________________________

o I am not responsible to any damage caused through the use or misuse
of this product and so it must only be used at your own risk.  All
efforts have been made to ensure the stability of the program but
this does not mean it is 100% safe.  Please backup any important data
that could be damaged through the use of this software until you are
sure that it is stable...Amen.

Donations/Comments ___________________________________________________

Any comments or donations can be sent to:

 PSR Software
 Paul Ruane
 26 Birdwood Close,
 Selsdon, Surrey.
 CR2 8QG.

I may also be contacted at the following addresses as Paul Ruane:

 Fidonet_____
 2:252/149.3
 2:253/516.12

 Amiganet____
 39:135/14.3
 39:135/13.12

_________________________________________________________________NULL_