[news.software.b] centralized .newsrcs

henry@utzoo.uucp (Henry Spencer) (01/01/90)

In article <1989Dec31.201228.20374@ladc.bull.com> frank@ladc.bull.com (Frank Mayhar) writes:
>Certainly this would require some changes to the news readers, and to NNTP.
>But I think it would be worthwhile, and not too difficult to implement.

You would have to revise a *lot* of software.  A year or two ago, Geoff
and I counted ten widely-used news readers without even trying hard.
There are undoubtedly more than that.  And the code inside some of those
is, uh, well, shall we say "stiff reading"?  It's years too late for any
substantial revision of how the .newsrc stuff is stored and handled.

In any case, I think it's wasted effort.  Monitoring of .newsrcs is useful
in precisely the situation where such convolutions are *not* necessary:
a small, simple machine with only a few users, who can be counted on to
keep up with the news.  Postulate one user who likes to read news from
time to time but doesn't do it regularly, and you're in trouble.  Any
large system will have dozens, if not hundreds, of such people.
-- 
1972: Saturn V #15 flight-ready|     Henry Spencer at U of Toronto Zoology
1989: birds nesting in engines | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (01/02/90)

In article <1990Jan1.063940.681@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:

| You would have to revise a *lot* of software.  A year or two ago, Geoff
| and I counted ten widely-used news readers without even trying hard.
| There are undoubtedly more than that.  And the code inside some of those
| is, uh, well, shall we say "stiff reading"?  It's years too late for any
| substantial revision of how the .newsrc stuff is stored and handled.

  You're right in what you say, but I certainly think that there is room
for a site to install either a new newsreader which uses another file,
or code for another file which can be dropped into popular readers.
Although newstree currently uses newsrc, the interface was designed to
allow other scoreboards if needed.

  The effort required to change the existing code is at least as great
as you imply, and much of it written with the dictum that "if it was
hard to write it should be hard to understand."
| 
| In any case, I think it's wasted effort.  Monitoring of .newsrcs is useful
| in precisely the situation where such convolutions are *not* necessary:
| a small, simple machine with only a few users, who can be counted on to
| keep up with the news.  Postulate one user who likes to read news from
| time to time but doesn't do it regularly, and you're in trouble.  Any
| large system will have dozens, if not hundreds, of such people.

  Has someone looked into keeping a scoreboard of average time for an
article to be read by xx% of the readers (by group)? This is one of
these things which seems to need a prototype system to evaluate, since
a useful model of user behavior is likely to be harder to generate than
the score keeper.

  What I am thinking of is some way to determine the time an article
must stay on a system to be read by at least xx% of the readers, and
adjusting the expire to match. Obviously the current expire time affects
the user practice; on a system with three day expire everyone reads news
on Monday morning... goes without saying.
-- 
	bill davidsen - sysop *IX BBS and Public Access UNIX
davidsen@sixhub.uucp		...!uunet!crdgw1!sixhub!davidsen

"Getting old is bad, but it beats the hell out of the alternative" -anon