Let me say how much I agree with Jeff's comments. It truly is difficult
sometimes (thankfully not too often) to keep from saying "screw it, I'm
fed up with all of this; it's not worth the hassle." But then, I calm
down and try to come to a better solution to whatever the miserable
situation is. It truly is one of the most frustrating, disgusting,
marvelous, delightful education experiences I've ever had.
Eric: I've never been to a summer camp, so I can't sing Michael's
camp song. But I certainly want to thank you for all the work you
put into this project. As someone who puts a lot of work into
another project, I know from experience how important it is to get
Bravo's occasionally, and if anyone deserves them, you do.
Certainly getting mad at each other is not going to help any of us.
Certainly we need to find a solution to the problem we've managed to
find ourselves in.
Certainly it's unfortunate that the original LISTSERV design didn't
anticipate the need for such expansion, but we ALL make design decisions
(or non-decisions) that come back to haunt us later. I know I have.
What we have to do now is figure out a way of the hole.
A modest proposal:
Given: Automatic updates of a package from an outside source are
unacceptable to some people, because of the security and other risks
involved, regardless of how well trusted the outside source is.
Given: Updates to a package from an outside source which causes the previously
working package to fail are unacceptable to most people.
Given: LISTSERV cannot handle more than 65 (? I forget the actual number)
of entries in PEERS NAMES at levels below 1.5i, and there are more
sites that would like to become part of the LISTSERV network, but
cannot officially do so until this problem is fixed, since adding
these people to the table will cause 1.5h (?) and lower versions
to crash.
Given: No solution is viable which demands Eric to dedicate his entire
life to LISTSERV, or even much more of it than he is doing now,
which is considerable.
Possible way out?
1. To avoid the security problems of automatic update, send any updates to
the LISTSERV postmaster, including PEERS NAMES, plus mail informing the
postmaster of the need to pass the file to his or her local LISTSERV.
While this may seem to introduce more problems than it solves, since
there will no longer be a guarantee that every LISTSERV is updated
at the same time, in fact that guarantee isn't valid right now, since
network delays, link failures, etc. frequently will delay or lose 1 or more
copies. And not updating BITEARN NODES often enough will cause almost
as much if not more trouble than not having PEERS NAMES updated
simultaneously.
2. Spread the work of updating PEERS NAMES around. When a new site
obtains LISTSERV, instead of reshipping the entire PEERS NAMES file,
ship only the new entry to the existing postmasters, and a complete
copy to the new site. When an existing site updates their PEERS NAMES
entry, send that entry to Eric for resending to the LISTSERV network.
Surely one of us can write a tool for updating PEERS NAMES entries.
If I weren't going to be gone for 3 weeks starting Saturday, I'd offer
to do it myself. Something like the UPDNODES file we all use
to update our copy of BITEARN NODES should do the trick.
Because some sites might eventually decide to drop LISTSERV, for whatever
reason, the update capability must include deleting entries. Again,
UPDNODES already does something similar, so it shouldn't be hard.
For all I know, Eric, you've already written and are using something
like this anyway.
If Eric gets drafted or whatever, then someone else will have to take
over this function.
3. Once we start sending only PEERS NAMES updates (where have I heard this
discussion before), then send out an update which
a. Removes backlevel (choose whatever unsupported level you wish) nodes
from the file
b. Adds the new nodes as needed.
The message sent to the postmasters along with this update can then
WARN them that they should NOT apply the update unless they are at 1.5i
(or whatever level is important). If they choose to ignore the warning,
and crash their own LISTSERV at that point, that's their own problem -
if they choose to shoot themselves in the foot, it's their finger on the
trigger.
This means:
a. The backlevel people will continue to run on their own systems, and
local lists will run fine. I don't know for sure what will happen
if they try to DISTRIBUTE to nodes that no longer recognize them.
But, and this is the key, if they do have problems using
DISTRIBUTE, then they need only upgrade their LISTSERV, send the
update to PEERS NAMES to Eric and then when an update to PEERS NAMES
is distributed to the entire network, adding them back in, they
can apply the update and rejoin the world. Since I suspect that
the downlevel nodes are not doing DISTRIBUTE too much, this should
not be too much of a problem, and an encouragement to upgrade.
I don't mind saying, "if you don't upgrade we won't talk to you"; it's
"if you don't upgrade I'll shoot you" that causes me trouble.
b. New people will be able to join the LISTSERV network.
c. Current level people will see old level people disappear. As far
as I know, that won't hurt peered lists, but merely keep them from
sending DISTRIBUTE jobs to the downlevel sites.
d. This solution is general; if some other condition occurs in the future
that requires cutting off a certain version and lower, no new structure
needs to be invented.
e. We're saving ourselves from that inevitable point down the road where
PEERS NAMES becomes as big a bother as the BITNET/EARN/NETNORTH routing
tables have already become. Let's pretend we've learned that lesson.
f. It's not much, if any, extra work for Eric (or anyone else) to send
out the changes instead of the entire file. Instead of doing a
PUT to every server, all he should have to do is build a DISTRIBUTE
job to all the postmasters.
Regards,
Richard
|
