ronald@robobar.co.uk (Ronald S H Khoo) (08/28/90)
It has been pointed out to me that sys file entries like: stl:scot/all,!local:f stl/ibmpcug:all/all,!local:f are actually quite a nice way to go, but C News doesn't hack this properly. The purpose of this is as follows: ibmpcug is my main news feed, but its news feed doesn't get scot so it takes scot from me, which I get from stl. Only scot needs to be fed back to stl from ibmpcug, but anything that's locally generated as well as anything generated from leaf sites connected to me get sent to stl anyway, to improve local connectivity. The problem is that C News treats all sys file entries independently, so, e.g. a local article posted to scot.test would satisfy BOTH criteria and be entered TWICE in stl/togo. B News only queues it once in this case, I'm told. Would it cost too much to do a "remove the duplicates" pass once the "sites togo" list is generated ? Or is there a better way to do this? It certainly looks like a nice and "tidy" way to arrange the sys file. -- Eunet: Ronald.Khoo@robobar.Co.Uk Phone: +44 81 991 1142 Fax: +44 81 998 8343 Paper: Robobar Ltd. 22 Wadsworth Road, Perivale, Middx., UB6 7JD ENGLAND.
henry@zoo.toronto.edu (Henry Spencer) (08/29/90)
In article <1990Aug28.123323.2598@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: > stl:scot/all,!local:f > stl/ibmpcug:all/all,!local:f >The problem is that C News treats all sys file entries independently, >so, e.g. a local article posted to scot.test would satisfy BOTH criteria >and be entered TWICE in stl/togo. B News only queues it once in this >case, I'm told. In this particular case, it's easy enough to fix with a ",!scot" in the second line. In general, it does seem a bit silly to add the same name to the same file twice, but I'm not familiar with the code and can't say what would be involved in doing something about this. There is also the question of whether interesting tricks can be played that *depend* on the lines being independent... >Would it cost too much to do a "remove the duplicates" pass once the >"sites togo" list is generated ? Or is there a better way to do this? A "sort -u" would remove the duplicates, but it does not seem worth doing as a standard thing, given that this situation rarely crops up and a sort is not a particularly cheap operation. On an unrelated topic, something we should perhaps address in documentation is that there seems to be a popular myth that "!local" in the distribution subfield has some kind of magic effect. It doesn't. Unless your local articles actually contain "Distribution: local" lines, "!local" is quite meaningless. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
jimb@silvlis.com (Jim Budler) (08/29/90)
In article <1990Aug28.172106.20512@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: > >On an unrelated topic, something we should perhaps address in documentation >is that there seems to be a popular myth that "!local" in the distribution >subfield has some kind of magic effect. It doesn't. Unless your local >articles actually contain "Distribution: local" lines, "!local" is quite >meaningless. Well for me it had the effect of preventing rebroadcast of spaf's checkgroups, which come with "Distribution: local". With a distribution of "all" they get rebroadcast, however with "all,!local" they do not. I agree it is not magic. It just works. >-- >TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology >OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry jim -- Jim Budler jimb@silvlis.com +1.408.991.6061 Silvar-Lisco, Inc. 703 E. Evelyn Ave. Sunnyvale, Ca. 94086
tale@turing.cs.rpi.edu (David C Lawrence) (08/29/90)
In <1990Aug28.172106.20512@zoo.toronto.edu> henry@zoo.toronto.edu
(Henry Spencer):
On an unrelated topic, something we should perhaps address in documentation
is that there seems to be a popular myth that "!local" in the distribution
subfield has some kind of magic effect. It doesn't. Unless your local
articles actually contain "Distribution: local" lines, "!local" is quite
meaningless.
One thing about this "popular myth" is that it is very useful, Henry,
and I wish you wouldn't attempt to _discourage_ it. If you instruct
your users that there is such a thing as a Distribution: local, even
indirectly as the answer for the most restrictive distribution
question in rn's Configure, than of course when the articles do
contain it they should be restricted. I personally have
/all,!local,!rpi in most of my sys entries and I don't consider it to
be some sort of "magic effect". I use local distribution for
checkgroups messages (son of a gun! isn't that what spaf puts in the
sample checkgroups messages?) and burst digests; I could use an
organisation prefix but since other people use my script to burst
digests too I made it a nice generic local. Also, some other sites
get rpi.* and I really don't want to be inflicting my own personal
checkgroups on them. (Simple fix for that too, I know. Just start
doing checkgroups without posting them; feed it to ctl/checkgroups
directly.)
Do you know what the intended distribution of
alt.swedish.chef.bork.bork.bork was? C'mon, one guess. Somehow this
person got a notion that Distribution: local meant something, and it
isn't that terrible to have a nice generic notion like that which can
be carried from site to site by users. I am under the impression that
perhaps this person got the notion from when they ran B News and local
was special cased (does B News do that in the code?). Another thing
that lends itself to this impression is that when I _wasn't_ blocking
local I would get complaints from B News sites I fed which were
getting "bogus local distribution rejected!" messages filling their
logs as their nntpd kept spewing back rejected-try-again codes and my
site kept trying to offer the articles. I think this only happened
with control articles that came through. I also don't know whether
this was because !local was in his ME: line, but I think it does have
it there -- whether it did at the time, I don't know. It's sort of a
mystery to me what those problems were since I didn't poke through the
B News sources and his sys file.
The nice "magic effect" I get by putting !local in my sys entries is
certainly worth having it there. !local is not at all meaningless at
my site, even when my own local articles (which often contain
"Distribution: rpi" which does in fact get a wider distribution than
local) do not contain it because it means I am not forwarding articles
that I received which someone else really seemingly intended to not go
anywhere.
--
(setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))
The most remarkable thing about looking at a picture of myself was the sudden
realisation that my hair is in fact parted on the left and not the right.tale@turing.cs.rpi.edu (David C Lawrence) (08/29/90)
In article <YM=%=1_@rpi.edu> tale@turing.cs.rpi.edu (me) asked about B
News sites and special-casing local distributions. Well, just now,
while trying to track down another problem I having between B News
sites that are rejecting articles which C News sites are taking fine,
causing nntplink to deluge the site with articles it can't take -- and
which it reports to the B News admins as garbled news -- I came upon
this: (breathe)
200 masscomp NNTP server version 1.5.6 (27 August 89) ready at Wed Aug 29 02:29:32 1990 (posting ok).
IHAVE <versionm@rpi.edu>
335 Ok
Path: rpi!tale
From: tale@rpi.edu
Newsgroups: control
Subject: version
Message-ID: <versionm@rpi.edu>
Date: 29 Aug 90 06:35:22 GMT
Lines: 1
Control: version
Distribution: local
checking your version of news
.
436 inews: Bogus local distribution rejected\
QUIT
205 masscomp closing connection. Goodbye.
(I was trying to just ask for this fellow's news version at this late
hour without asking the whole net for it and crossing my fingers that
he wouldn't propagate the article.)
The garbled news problem? Beats me. One that masscomp is whining
about now doesn't have a Date: header, which seems to be why it is
saying inbound news is garbled. God only knows what the problems with
the others are. B News sites are also choking on "Sender:
news@zip.eecs.umich.edu (\nNot Available)", where the \n is a newline
in that field, though I talked to an admin there last week and as far
as I know she has fixed that problem by now.
--
(setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))
The most remarkable thing about looking at a picture of myself was the sudden
realisation that my hair is in fact parted on the left and not the right.henry@zoo.toronto.edu (Henry Spencer) (08/30/90)
In article <YM=%=1_@rpi.edu> tale@turing.cs.rpi.edu (David C Lawrence) writes: >One thing about this "popular myth" is that it is very useful, Henry, >and I wish you wouldn't attempt to _discourage_ it... The idea of a "local" distribution has merit. The belief that it will automatically do the right thing, everywhere, without attention, on the other hand, is badly misguided. As witness: >Do you know what the intended distribution of >alt.swedish.chef.bork.bork.bork was? C'mon, one guess. Somehow this >person got a notion that Distribution: local meant something... -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
jimb@silvlis.com (Jim Budler) (08/30/90)
In article <1990Aug29.184257.25@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <YM=%=1_@rpi.edu> tale@turing.cs.rpi.edu (David C Lawrence) writes: >>One thing about this "popular myth" is that it is very useful, Henry, >>and I wish you wouldn't attempt to _discourage_ it... > >The idea of a "local" distribution has merit. The belief that it will >automatically do the right thing, everywhere, without attention, on the >other hand, is badly misguided. As witness: > The problem boils down to an undocumented "B-news" "feature" that Distribution: local *was* magic. So was world. I welcome and like the seperation of newsgroups and distribution that Cnews started. I think your (Henry's) message at the start of this thread was too easily (mis)interpreted as discouraging the use of /all,!local in Cnews sys files, instead of promoting the information that the Distribution: local has no defined meaning in Cnews. I had a slight mail interchange with Geoff on this problem some time ago which I didn't pursue, since I had a workaround. I was jim@eda.com at the time if Geoff wants to check. I feel that the problem is completely documentation, and not a problem requiring any code changes. The *undocumented* behaviour of B-news was that Distribution: local was special. But after several years of use this was *expected* behaviour by many admins. I believe the Cnews documentation should mention this difference in the same place it documents the "/" which seperates newsgroups from distribution. A paragraph similar to this would suffice: "Bnews appears to treat "world" and "local" as special cases when matching sys file entries to Distribution headers. Cnews, on the other hand has only one special case distribution, all. The closest approximation of a typical Bnews sys file entry: neighbor:world,comp,sys,news:: is probably: neighbor:comp,sci,news:: or neighbor:comp,sci,news/all,!local::" Now I may have this a little wrong, but my paragraph does demonstrate the fact that the Cnews distribution "all" is not the same as the Bnews distribution "world". But hey, the problem here is only minor. When Bnews introduced "world" news stopped flowing along the expected paths. When Cnews introduced "all" the news started flowing along unexpected paths. Which is worse? jim -- Jim Budler jimb@silvlis.com +1.408.991.6061 Silvar-Lisco, Inc. 703 E. Evelyn Ave. Sunnyvale, Ca. 94086
henry@zoo.toronto.edu (Henry Spencer) (08/31/90)
In article <1990Aug30.065506.20290@silvlis.com> jimb@silvlis.com (Jim Budler) writes: >.... I feel that the problem is >completely documentation, and not a problem requiring any code changes. I'll go along on that one! Actually, C News does have one or two "magic" distribution names for ihave/sendme, but otherwise your summary is correct: "all" is the only special word in distributions. Documentation will be amended to mention this. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry