Well, well, there is truth to both sides, but please note that:
- DISTRIBUTE will be used AUTOMATICALLY by LISTSERV when distributing files to
a list. Only files, not mail. Mail items are typically small and would not
gain much from being DISTRIBUTEd, ie this is perhaps not worth the added CPU
time and problem when the neighbour's server is on vacations ( ;-) ). However
you should note that the current implementation of the file distribution
feature is very unsatisfactory:
1) You don't know who sent the file. With DISTRIBUTE you know.
2) The routine that avoids loop is VERY poor. It works without problem when
everything is ok, but the one implemented for MAIL is much more solid
and will detect loops that the file distribution one will not. The last
routine I implemented in DISTRIBUTE has a "VIA" dataset which gathers
the userid@nodes of all the lists which participated in the file distri-
bution and stop the process as soon as a duplicate is found. This is an
excellent protection against loops. Note that it can still loop if there
is an "old" server in the path which trashes the "VIA" dataset... :-(
3) Because of (1) the ACK/NOACK/MSGACK option is not respected. You don't
know when your file has been received. No problem to respect it with
DISTRIBUTE.
4) It doesn't work for ARPA recipients. DISTRIBUTE does, and will even
use the best path to route the file to its appropriate gateway...
I therefore think that DISTRIBUTE has GOOD reasons to be a part of LISTSERV.
However, this does not mean that it cannot be isolated from LISTSERV and ran
as a specialized server. The current code would cause some problems since the
server would be registrated as a normal LISTSERV but there would be no pro-
blem maintaining a separate list for DISTRIBUTE-only servers. If people are
interested in running a server just for DISTRIBUTE I could provide a separate
package and separate servers list...
- If you split LISTSERV into MAILSERV, DISTSERV and FILESERV, you have a very
significant duplication of code and datafiles. Just try it... :-) I bet
more than 50% of the code/datafiles is shared between the three functions.
- You can distribute a file to a LISTSERV list by making it the only recipient
of the DISTRIBUTE job (that will be done automatically in the future when you
send to a list). A DISTSERV could not, of course.
- Similarly, you can restrict access to a file to a given list of people. That
means if you want something which is not just GET = ALL/LCL/some list of
nodes/some list of userid@node which will not change very often, you have to
write code to maintain the list more efficiently than just logging on to the
server, stop it, XEDIT the filelist, etc. Nothing prevents you from creating
a LISTSERV list WITHOUT the associated dummy userid, ie a list you won't be
able to mail to, just for defining who can retrieve a file or set of file.
This could be the list of CS students working on AI projects for example.
- Maintenance of one single server is easier than that of three servers. Espe-
cially if you need to provide the three of them with a copy of BITEARN NODES
which you must update every month, and re-issue a NODESGEN to the three of
them
But of course you may not need the file-server functions at all and be concer-
ned about the disk space they require. But it's not that much actually. As for
the "selling" aspect of the thing, I'd say that people would be more interested
in a server that can do mailing, has powerful file-server functions, and has
the DISTRIBUTE thing but requires only 3 cyls of 3350, than in three different
servers. If they need only one or two of the three above functions they might
still find a use for the last one in the future. This is especially true for
the file-server functions which everybody can find a use for as soon as there
is a program developped by someone at the local node which is to be made avai-
lable to the network without having to worry about sending updates automatical-
ly, etc. Granted, Netserv is here for that but Netserv is not designed to dis-
tribute packages which have nothing to do with the network such as mods to the
PASCALVS compiler :-) And there is often a need for a local file server for
local-node-only use in each big installation -- even here at FRECP11 we had
this need...
Eric
|
