> (1) The default limit be raised to at least 5 times the current (256kb) > limit The current limit is already very high, if each single user in the network were allowed to order 1.2 Mb of data a day from each server, it would be like having no limit at all. > In addition, a whole package should be sent when requested, That is right, and I'll do something about it as soon as the EARN business is done with. As I might already have said (or forgotten to say), I won't distribute any change to LISTSERV until after the EARN business is over, because some people have insinuated that I would make sure to introduce serious bugs in LISTSERV before I hand it over to EARN. By giving the present FIX15O1 version, unchanged since 17-Jan-89, to EARN, I will make sure that nobody can seriously pretend I have acted in such a way. > (2) The limits should not be time wise, but should be based on the number of > links crossed (...) That's too complicated, both to code and to explain to an end-user. That would also eat a lot of CPU time. In any case, LSV$GETQ is an exit so that you can code whatever you want into it. > (3) Some sort of mechanism should be put into place so that you must > confirm that you want a specific file a second time during a 24 hour period > and this confirm mechanism will allow that you can not just specify > 'override' on every command, but that it must be in response to a Listser > advisory It must be possible to specify 'override' on any command, because you might have a service machine or somesuch requesting a file from LISTSERV, and you don't want to wait for a mail reply to the command (messages can't be trusted as you know), read it, resend the command with the confirmation, and eventually get the file. I had planned to do this but the problem is to remember who got what file and when, which is why I wanted to make it part of the file stats support that I planned to introduce some day (all of that was before EARN decided they needed to own LISTSERV, of course). > (4) If some sort of regional association of backbone sites could be formed > (...) > > (a) The sub-server that has the file because of space considerations at the > main (regional) server site, or; > > (b) A server that is closer to the site that is requesting the file than the > regional server, and the files have been sub-stored on that server, or the > site is in fact a closer regional server. (b) might be down at the time of the request, which might be the reason why the request was not sent there in the first place. An override option is therefore required. In any case this is a LOT of work - having to keep track of what server has what file, keeping that information up to date, regardless of the order in which the updates arrive, of lost files, etc... You're asking for something as complicated as the UDD database, and that takes time to implement. > All files have an origin point and are sent to this origin by the person > making the updates. What if it is down? How can I update the other peers? > This Listserv then sends the update job to all other regional servers > housing the file in question. The Regional server then updates all its local > sub-servers. What is a "local sub-server"? Who defines to which region a given server belongs? What happens if network delays cause a server to be in no region, or more than one region, for a transient but non-negligible amount of time? Eric