igb@fulcrum.bt.co.uk (Ian G Batten) (01/05/90)
I've just off-loaded my news-reading overhead from our news spool machine; people now read news with rrn or xrn from other hosts. Is there any received wisdom on how best to manage my arbitron returns? ian -- Ian G Batten, BT Fulcrum - igb@fulcrum.bt.co.uk - ...!uunet!ukc!fulcrum!igb
ambar@bloom-beacon.mit.edu (Jean Marie Diaz) (01/06/90)
From: igb@fulcrum.bt.co.uk (Ian G Batten)
Date: 5 Jan 90 10:56:15 GMT
I've just off-loaded my news-reading overhead from our news spool
machine; people now read news with rrn or xrn from other hosts. Is
there any received wisdom on how best to manage my arbitron returns?
If you control all those other hosts, then running arbitron on each one
is at least feasible.
The best thing (IMHO) is to wait for the new NNTP protocol revision
which will have support for centrally-gathered statistics. (Any ETA,
Brian?)
(Then, of course, we'll have to wait for the implementation of same.
Heck, I've been waiting three years now to be able to contribute
arbitron statistics from MIT Project Athena; a few more months won't
hurt. :-)
AMBAR
ambar@bloom-beacon.mit.edu {mit-eddie,uunet}!bloom-beacon!ambar
But if a writer does not entertain his readers, all he is producing is
paper dirty on one side. -- Robert A. Heinlein, _Grumbles From The Grave_jv@mh.nl (Johan Vromans) (01/07/90)
In article <%YJ$W$@masalla.fulcrum.bt.co.uk> igb@fulcrum.bt.co.uk (Ian G Batten) writes: > I've just off-loaded my news-reading overhead from our news spool > machine; people now read news with rrn or xrn from other hosts. Is > there any received wisdom on how best to manage my arbitron returns? Yes, there is. I have rewritten arbitron in perl, and added the capability to start slave processes on nntp-slave hosts to gather the statistics. At the end, all newsreaders detected on the slave hosts will count as newsreaders on the originating host so it will yield the same results as if all newsreaders had been physically present on the originating host. I've sent a copy to Brian Reid, who promised to incorporate it in the arbitron distributions, but I haven't seen it coming back yet (Brian, are you there?). We agreed upon a special identification to tell the ordinary arbitron, the notesfile arbitron and the perl arbitron [also the VMS arbitron?] apart, so the final word is his. For this reason I'm very reluctant giving copies away, since it may not work as expected. Johan -- -- Johan Vromans jv@mh.nl via internet backbones Multihouse Automatisering bv uucp: ..!{uunet,hp4nl}!mh.nl!jv Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62944/62500 ------------------------ "Arms are made for hugging" -------------------------
david@ms.uky.edu (David Herron -- a slipped disk) (01/16/90)
When I wrote the scripts which became arbitron NNTP wasn't even
a twinkle in anybody's eyes, at least not that I know of.
Think about the information that's available to an NNTP-less system,
you've got the active file and peoples' .newsrc files. In an NNTP-full
system you have nearly the same thing -- the .newsrc files are
elsewhere though. As Ambar suggested, if you can 'control' the reading
hosts then you can somehow bring the .newsrc & active file information
into one place.
erm, I haven't studied the NNTP protocol very closely, despite having
made heavy use of it and having been on the mailing lists involved in
it's development for years, so I'm not certain how possible this is.
As I recall there's a way of telling a difference between a newsreader
client and a news-neighbor client, if only that a newsreader client
will use a different set of commands than a news-neighbor client. If
this is do-able then bugging your NNTP server to log information about
what a person read could provide you arbitron-like information. In
fact, it would be more accurate... (Arbitron is easily fooled by rn's
"catch-up" command)
Seperate protocols for news reading and news-neighbor-activities would be
useful if only from an administrative point of view.
--
<- David Herron; an MMDF guy <david@ms.uky.edu>
<- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- New official address: attmail!sparsdev!dsh@attunix.att.com