FTS v5.0 Prospective Technical Specs

              FTS v5.0 Prospective Technical Specs

 --- FTS:

 File Transfer System was originally the system for file lists and

requests. It will now be the term used to refer to the entire system, instead of the bulky FDL/FTS. This helps prevent the next move, which would have been FDL/FTS/BLT. Now, FDL and BLT will be parts of a more integrated FTS.

 --- BLT:

 Binary List Transfer is my name for a dir listing for which updates

are sent out when new files are uploaded.

 --- BLTREC:

 There are many things to take into account for an updatable listing.

I have tried to address them all. (?) means I am unsure if this should be included. We also need to take into account merged lists.

 For file entries: filename[13], size, upload date, upload usernum,

upload sysnum, list sysnum(?), description[81], listdate(?), extended desc(?), times requested/downloaded(?);

 For directories: dirname[81], category, listownersys, flags,

numfiles(?), last update(?), dirtype9;

 I am thinking of one data file for each directory, with the directory

record at the top. All these files will be in their own seperate directory to reduce confusion.

 --- FDL:

 File Distribution List is what a networked directory is called. In

FTS v5.0 it will no longer be regarded as a seperate system, but rather as a subset of the FTS. And FDL will also be a BLT by design. It's a simple matter of checking a second subscriber file and can easily be incorporated. (see fdl.exe)

 --- FDL.HEADER:

 Sysname is given a value in de602 which is never used by de601. It IS

used in de600 for FDL add/drop requests. We could use sysname for the new alphanumeric dirtypes, except for add/drop requests, where we can use the filename field instead, which is unused in de600. Or, if I move to the SSM instead of e-mail, sysname could be used here as well, making it uniform. I would then simply change the name of the field to dirtype.

 --- FDL.EXE and F<fdl>.NET

 The replacement program (probably fts.exe) will look at the dirtype

setting in diredit (see stock dirtype) to see which dirs are hosted FDL's and BLT's. It will update those new files it finds.

 The filename for the list of subscribers will be <dirtype>.FDL (vice

F.NET) or .BLT. This naming scheme will allow full use for the alphanumeric dirtypes. These will be kept in the network directory along with the *.MRK files which the current fdl.exe uses to find new files. This will eliminate the problem where a new FDL Host hast to wait for the update to come through just to set the mark for his directory.

[new note: Use it to send files on postable FDL's as well.]

 --- STOCK DIRTYPE:

 The stock dirtype setting in diredit will become the flag field in

the new system. FINIT will be used to set these so that we can obtain 5 digits as long as it doesn't exceed 65534. By limiting the first number to 5 (giving us up to 60 categories including 00), we will have a full 0-9 on the other 4 digits. Here is a TENTATIVE breakdown of the 5 positions (ABCDE):

 A & B: Category of directory.

 C:
    0 - Non Published (? add 4-6 for nonpub of the following?)
    1 - Regular Users
    2 - Sysop's Only
    3 - WWIV Registered Sysop's ONLY

 D:
    0 - Not Host
    1 - Host
    2 - Incoming merged, not hosted
    3 - Merged, Hosted

 E:
    0 - No list generated, No files requestable.
    1 - No list will be generated, but files may be requested.
    2 - List/Files may be requested, no updates (List)
    3 - Updated Lists Generated, files may be requested. (BLT)
    4 - New Files and New Listing updates generated. (FDL)
 
 --- NEW DIRTYPE:

 The new dirtype for all directories will simply be the entire 8

character string of the name of the directory data file. FINIT, or a simple mod, will allow sysops to change the name of existing files on the fly. (see below)

 --- FINIT.EXE & FINIT.MOD:

 FINIT will allow the setting of 5 digit stock dirtypes by asking

questions similar the the way flags are set for subs. It will have a complete set of conversion routines to read dirlist.fts, fdl.cfg, and the fdl settings in fdlfts.cfg to set the appropriate flags. It will also need to create some sort of data file which will be read by FTS for incoming packets in the case of merged lists and fdl's.

 FINIT will also send add/drop requests in the very same manner that

WWIV does for subs.

 --- DIRS.LST:

 subs.fdl will go away, being incorporated into dirs.lst (and .0, .1,

etc.) which will list all directories for which lists may be requested, or files requested from, blt's and fdl's as well. I still want to stay with 4 flag positions, and I think I have them worked out (1234):

 1:
    R - Add/Drops AutoRequestable (FDL/BLT)
    L - List Only

 2:
    B - BLT
    F - FDL
    P - Postable FDL

 3:
    W - WWIV Registered Sysops ONLY
    S - Sysops ONLY

 4:
    C - CD Rom
    M - Merged (FDL/BLT)
    O - Offline Files (?)

 --- DE3 (old DE603)

 Information for dirs.lst will be pinged by the Dirs Coordinator (the

FDL Coordinator position, expanded). NetSend's de603 is being revamped at this time for just this purpose. The new file will be de3, which will replace de603. This will cause a little less confusion about what is NetSend and what is part of FTS.

 --- DE603 (new for v5.0) (?)

 I am considering using a new de603 for the BLT handling. It would

need to place incoming BLT updates into the appropriate files. DE601 already does far too much, and has become a bit too large. I may also move standard list generation here as well.

 --- DE600

 The FDL add/drop routines are easily adapted to handle BLT add/drops

as well. I would, however, like to change from type 2 messages (e-mail) to type 15 (SSM) and imitate the add/drop notices sor subs in standard WWIV. I would then add a function to create e-mail for cases where the FDL or BLT is set to be handled manually. All responses will still be e-mail, again imitating standard WWIV sub handling.

 --- CATEG.FTS

 Dirs will be categorized in the same manner as subs. This is the file

that will contain the categories. Here is what I have so far:

 1. FILEnet Sysop Utilities (NFT/PPP/FTS/ETC)
 2. Sysop Utilities
 3. BBS Online Games
 4. Computer Utilities
 5. Virus Scanners
 6. DOS
 7. Offline Games
 8. Windows
 9. Windows Games
10. OS/2
11. OS/2 Games
12. Software by the Author
13. Graphics (GIF/JPG/ANSI/PCX/ETC)
14. Sound (VOC/MID/WAV/ETC)
15. Internet
 0. Misc.

 --- RESERVED DIRTYPE 9999

 I would like to replace this will a setting in FINIT which will place

the incoming requests in a directory pointed to by filename (aka dirtype). It will still default to the sysop directory. The same goes for pgp keys. This allows us to remove the reserved dirtypes and allows for expansion. We could have seperate direcories for NFT (or Offline) requested files and Online User Requested files, as well as a directory for files not requested, but sent to a user other than #1. We could even have a dir for files "attached" to e-mail.

 --- OFFLINE FILE REQUESTS

 This idea has been growing on me. It would be a way to have someone

request a file from you that you don't always keep online, such as a CD. Where the O flag is set, or an exist check fails for a CD file, the request would be sent to a file to await action by the sysop. NFT could be used to process these. It really seems a better place for them than FINIT.

 --- FDLFTS.CFG

 These settings will only be needed for NFT and FTS.EXE. Could we use

a data file set up by FINIT? Perhaps we could retain one small text file called FTS.INI to contain these.

MAIN_BBS C:\WWIV
MAX_LOG 100 LOG_PATH C:\WWIV\NET\FILE\

 This option should simply be eliminated. It is useless for debugging.

VERBOSE 1

 Ah! Pregenerated list files. Perhaps if <dirname>.PGL exists, FTS

simply sends that instead of generating a new list. The following options will be useless in the new system. FINIT would also have an option to generate the PGL files. This will also come in handy when I work out the details for Offline File Requests. (See Above)

LIST_FILE Lnnn.FTS LIST_PATH C:\WWIV\NET\FILE\

 These would all be set in FINIT and the data stored in a binary data

file.

 (You will also notice something which helped prompt me to revamp the

whole system. Each of the following requires two lines to be edited by the sysop, but only ONE is required. In the first example, UB1 could easily be checked for in dirs.dat to find the path. The same goes for all such entries. The final straw was when I realized how completely useless FDL.CFG was. There is not one item of data in FDL.CFG that cannot be found in another file that was also being opened. It COULD have found the hosted FDL in FDLDATA.FDL and looked for the stock dirtype in DIRS.DAT, which would have given it the dirfilename and the path. The new system will simply use the data found in DIRS.DAT!)

: This one tells DE601 what directory to place file lists in. : Must be a WWIV dload dir.

ALT_PATH C:\DLOADS\MISC
ALT_DIR UB1

: This one tells DE601 what directory to place the Requests In. : Must be a WWIV dload dir.

REQUEST_PATH C:\DLOADS\MISC
REQUEST_DIR UB1

: This one tells DE601 what directory to place the Non-Requests In. : Must be a WWIV dload dir.

NOREQUEST_PATH C:\DLOADS\MISC
NOREQUEST_DIR UB1

 What can I look for to see if allow checking and updating should be

disabled?

DO_ALLOW YES

 The new system will look first in FINIT's data file to see if there

are any merges involved, and then simply put the file in the appropriate directory by dirtype.

FDL 119 UB1 c:\dloads\misc\

[End of Specs]