Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site steinmetz.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!ncsu!uvacs!edison!steinmetz!putnam
From: putnam@steinmetz.UUCP (jefu)
Newsgroups: net.news.group
Subject: Overload
Message-ID: <269@steinmetz.UUCP>
Date: Sun, 15-Sep-85 09:38:44 EDT
Article-I.D.: steinmet.269
Posted: Sun Sep 15 09:38:44 1985
Date-Received: Tue, 17-Sep-85 04:55:31 EDT
References: <494@klipper.UUCP> <3500008@ccvaxa> <2168@ukma.UUCP>
Reply-To: putnam@kbsvax.UUCP (jefu)
Organization: GE CRD, Schenectady, NY
Lines: 87

A lot has been said in this group recently about net apocalypse,
death and destruction, and so forth.

It seems to me that there are three issues involved :
     1) Transmission overhead
     2) Storage overhead
     3) Human information overload
     
The first may be helped by faster modems, compression, and StarGate.  
Even with moderation, StarGate and the like would help to reduce overhead
in transmission.  

The second may be helped in several ways :
   Expiring groups on a per-group basis.
   Sites with many machines linked together by a fast LAN could build
     network news servers so that articles need only reside on a single 
     machine.  (Hasn't anyone done this?)
   Just not subscribing to 'irrelevant' groups.  This one is a problem,
     as the manager in charge of the machine may well decide that 
     (for instance) net.motss is not at all worthwhile, but that net.cycle
     is.  (parenthetically, i wonder if this could be construed as a 
     First Amendment problem).  
   Keeping articles in compressed format - spends cycles instead of sectors -
     not perhaps very viable, but at least worth considering.
   
The third issue concerns me much more than the others as i think that there
are technological solutions to the first two.  

I think that there may well be a solution to the third issue as well, but
it _might_ involve some major software hackery.   

First, the news software _must_ be fixed to screen out multiple readings
of the same message.  Either that, or multiple postings and duplicate
postings (via software error) should be forbidden.  The problem is that
multiple postings are often reasonable.  An example is a brief mention
i just posted on a book "Winning Ways For...", on a mathematical analysis
of game playing.  It was a response to an article in net.math on nim, but
i felt that if readers of net.books and net.games had not seen references
to the book that it was worth bringing it to their attention.  I really
dont think, though, that anyone should have to read it more than once.

Multiple postings to some groups are obnoxious, especially things 
multiply posted to net.flame, net.politics....  It might be worthwhile
to build a description into the newsgroup description and the 
'allow this posting?' code to allow or forbid multiple postings.
Something like "net.flame:no_multiple_postings", 
"net.women:multiple_posting_to net.abortion" and so forth.

But... 

I would like to propose a more fundamental change.  Now i cannot
propose a precise mechanism, especially in this distributed network,
but allow me to suggest a few examples...

A discussion starts off in (say) net.news.group about the coming 
net.apocalypse.  So, a new group is (automagically) created called
net.news.group.apocalypse, when, after a while, it becomes unused and
expire finally empties it, and perhaps waiting for a decent interval
of mourning, it is removed from the newsgroup list, its directory is 
deleted, and its gone.  This would make the news more like a directory
tree.  

If the reader could then at some given news level, browse the sublevels
and look at the interesting stuff there (ok, this does require a major
new news reading program, picky, picky, picky), the reader could then
choose to read only the subgroups of interest, and in each of these 
subgroups a single discussion would reside.  

I would propose that only one message on a topic would not cause the
sub-group to be generated, but that there be some lower bound (probably
small, maybe different for each group....)  For example in {net,mod}.sources,
posting all the pieces of and bug reports for a single program in a 
subgroup would facilitate finding the source when needed.

Hard to implement?  Yah, but not impossible.  sub-group names do not
have to be the same as the directory names where they are stored, but could
be generated from the Subject: line.

Dumb idea?  Breaks everything we have already?  Oh well, sorry i mentioned
it.  Back to the apocalypse which is already in progress....



-- 
               O                      -- jefu
       tell me all about              -- UUCP: edison!steinmetz!putnam
Anna Livia! I want to hear all....    -- ARPA: putnam@kbsvax.decnet@GE-CRD