Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!bloom-beacon!tut.cis.ohio-state.edu!rutgers!aramis.rutgers.edu!webber
From: webber@aramis.rutgers.edu.UUCP
Newsgroups: news.misc
Subject: Re: "NNTP has had a number of very bad effects on the net..."
Message-ID: 
Date: 12 Jul 88 17:26:23 GMT
References: <1830@looking.UUCP>  <4414@pasteur.Berkeley.Edu>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 30

In article <4414@pasteur.Berkeley.Edu>, faustus@ic.Berkeley.EDU (Wayne A. Christopher) writes:
< ...
< Since we don't have the old bandwidth constraints (uucp batching, etc),
< I think we should create some new ones.  How about adding a
< re-transmission delay into the news software, so that an article would
< wait at a particular site for at least a few hours (say) before being
< sent out again?  That way, the high-bandwidth newsgroups would have
< discussions with delays of a few days or so, instead of an hour or
< two.  We could set different delays for different newsgroups, so that
< cancel messages and "timely" groups like comp.risks and *.announce
< would move quickly, whereas soc.singles and comp.lang.c could move more
< slowly.  For binary and source groups it wouldn't make much of a
< difference, since they don't contain followups.

I hardly see anything timely about comp.risks.  It seems that waiting
until the facts were in could only help the group.  However, in general,
when anyone starts talking about this is how we should handle all the
groups except for a few, it is always difficult to tell if they are
saying this is how we should handle the groups they don't like or this
is how even the groups they like should be handled.

< The problem with this is that discussions would arrive at people at
< widely different times, and there would be a lot more followups about
< things that for most people are weeks old.
< 
< Does this sound sensible?

Yep.  It was.

---- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)