The following is a list of features under consideration for the next
release of Snarf.  If you have a feature you'd like to see that does not
appear here, or if you have some comments to make on these features, please
send WWIVnet e-mail to Graham Mainwaring #1 @9970.



* Have Snarf process file descriptions as well as just files.  This is a big
one.  When a user uploads a file, they will have to specify a description
for it somehow.  Also, if Snarf understands file descriptions, users will be
able to do things like download a list of files which are new since a
certain date.  In addition, this feature will allow Snarf to update WWIV's
file records for the number of times a file has been downloaded.  The
problem with this feature is that many WWIVs are modified and do not use
standard file formats.  Some method must be provided for making Snarf work
with modified userrecs and directoryrecs.

* Give the sysop the ability to break into chat with a user while they are
Snarfing.  (To be fair, perhaps also put a user option in SNARF CONFIG for
'refuse to accept chats from sysops'.)

* Become compatible with any !-@REMOTE@-! interface standards that develop,
or if none do, create one.  (If such a standard exists, I would like to hear
about it.)

* Allow protocols besides DSZ Zmodem.  Possibly even provide support for
bimodem.  However, this would require a method for negotiating between BBS
and user as to which protocols both systems understand.

* Provide Snarf companion utilities which generate and manipulate file
lists.  Perhaps even provide a menu & mouse driven shell for Snarf which
allows downloading files chosen from a multiple-select list box.  Possibly
do the user interface using Turbo Vision.

* Add some more security features.  For example, allow password-protection
of some directories.  Another option would be requiring a valid WWIV
username and password before allowing Snarf downloads.  Adding this feature
would allow sysops to maintain file ratios and restrictions for Snarf
downloads as well as regular downloads.  However, since this would require
reading userrecs, implementing this feature would require a solution to the
modified-file-structure problem.