donn@hp-dcd.UUCP (06/09/84)
This is slightly Machiavellian(sp??), but... The bait: Create a new version of news (3.0) with some feature that no-one (absolutely no-one) can do without. The trap: Add to it the ability to respond to .ctl messages that change a group name, and the concept of "symbolic links" to groups, such that, e.g. net.trivia and net.games.trivia are the same group. (A warning is generated if the old name is used.) This should be done so that if a message is recieved (as opposed to posted) in the "old" group, it ends up in the "new" one, thus even if an individual site does it wrong, the backbone sites will fix it. These two features should make it possible to restructure at will, and kills, once and for all, the problem with certain groups refusing to die, no matter how many times you kill them. As for the bait, the best one I can think of (howls of anguish in the background) is to incompatibly change the headers. (Flames on this item to /dev/null, please; I know it won't work for political reasons.) Anyone got a better suggestion for bait? Actually, if a version of news had the above features, and was widely enough distributed, the name translation would propigate to the other sites, anyway. The real problem is the "who will do it" problem. If it looks like a reality, I'd probably do it for notes (since I prefer it). I don't care to volunteer for news, however. (At times, ignorance is a blessing.) Donn Terry Hewlett-Packard, Ft. Collins. hplabs!hp-dcd!donn
chuqui@nsc.UUCP (Chuq Von Rospach) (06/15/84)
As I have mentioned before, I have finally bitten the bullet and
decided to do some serious hacking to inews. Right now I am in the
process of linting (!!! it is down from 30K or error messages to about
13K) the code and trying to clean up some of the more outrageous
problems and removing dead code from the source. When I finish that, I
am going to do the following things as well:
1) clean up batching support. My inews will support at least two forms of
batching: the batch/unbatch distributed in 2.10.1 and the peter gross
version of batching known as bnproc. Both will be compile time options
using define flags so you can compile in either (or both) only as you need
them. I expect that installing support for bnproc into inews will improve
batching performance significantly because the current setup requires two
process spawn for every message (that is about 600-800 processes a day
right now-- very expensive), two disk writes (one to /tmp, one to
/usr/spool/news) and a pipe (on 4.2 this uses IPC and is somewhat
expensive). I haven't really looked and the 2.10.1 batching but there is
probably room for improvement there as well.
2) I am going to be writing some structure into the main process of the
code. Currently the rnews portion of code is hacked into the rest of inews
with a state flag and a lot of if(state==PROC) blocks. Besides making it
almost unintelligible it causes rnews to do processing (like parameter
parsing for inews) that is unnecessary. I'm going to split out the
appropriate code into its own function where it belongs.
3) I've been adding bug fixes off the net when I find them to work.
4) For the sake of the proposed net restructuring, I am going to write a
routine that will scan a list of newsgroups and check them against a
table. If they are in that table the routine will rename them to a given
group. If you create a table such as:
net.trivia net.games.trivia
net.stat net.math.stat
this inews will update the header and store the message in the new homes. I
also plan on setting it up so that the message will be transmitted from the
site with the updated header so that we can install this stuff on the
backbones (I hope) and help isolate the net from those sites that don't
bother to update their active files for the sake of the rest of us (I'm
VERY tired of lazy system administrators, folks...).
5) I want to add a routine that strips illegal groups from the headers
before they are transmitted. I haven't decided whether it should be all
groups that get stripped or just non net.all groups.
6) I want to change inews so that if the only place a message goes is
'junk' it doesn't get transmitted. This goes very closely with #5.
Longer range plans include splitting the news source directory into
subdirectories, which is why the Makefile I posted is set up the way it is,
and turning things like funcs.c and ifuncs.c into their own subdirectories
that create libraries instead of those horrible HUGE .o files. Comments on
all of this are more than welcome, and I'll (of course) be posting my work
once I get it done and stable.
chuq
--
From the ledge of the seventh cornice: Chuq Von Rospach
{amd70,fortune,hplabs,ihnp4}!nsc!chuqui (408) 733-2600 x242
Love is the process of my leading you gently back to yourself.
- Saint Exuperylaura@utzoo.UUCP (Laura Creighton) (06/23/84)
My favourtite feature that ``nobody will be able to live without'' is to compact news so that the transmission costs are lower. I don't know whether it would be better to leave the compacted versions in /usr/spool/net/news/* or whether one should uncompact them on arrival. I suppose it depends on whether CPU crunch or disk space is the major bottle neck on your system. Laura Creighton utzoo!laura