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