Newsgroups: news.software.b
Path: utzoo!utgpu!cunews!micor!latour!ecicrl!clewis
From: clewis@ferret.ocunix.on.ca (Chris Lewis)
Subject: Re: How C-news checkgroups should work, a proposition
Message-ID: <1991Mar29.031712.6021@ferret.ocunix.on.ca>
Date: Fri, 29 Mar 91 03:17:12 GMT
References: <1991Mar25.195250.24700@rivm.nl>
Organization: Elegant Communications Inc, Ottawa, Canada

In article <1991Mar25.195250.24700@rivm.nl> a3@rivm05.rivm.nl (Adri Verhoef) writes:
>How checkgroups should work, a proposition.

The difficulty with this proposal is that it assumes that there is only
one "authority" for checkgroups.  In contrast, there's at least 3 major
ones, and quite a few minor ones.  Worse, their name-space overlaps, case
in point "inet" and "world" (the mainline USENET one).  This implies,
amongst other things, that there are logically *several* different "newsgroups"
files.  One other peripheral issue is that of backwards compatibility...
Frankly, given the way stock C-news checkgroups works (sorry H&G if my
info is out of date) and B-news still gets upset with the different
"authorities", you'll NEVER want to issue a real checkgroups anymore,
for too many machines do moderately unpleasant things to their administrators
when a checkgroups comes in, and we'll never get enough people to upgrade
their software.

This is an idea I came up with quite some time ago, but have never had
a chance to implement - it's similar to something else I've seen recently:

    1) Add an argument to the "Control: checkgroups" header.   The argument
       specifies the "authority" or "sphere of influence".  For example,
       Gene would post "world" (or usenet or whatever name we chose for
       it), then there'd be an "inet", "bionet" etc. etc. etc.
       Eg: "Control: checkgroups usenet"
    2) The body of the article looks like the current B-news and
       C-news mechanism.  It would be nice to have something capable of
       supporting some of the additional C-news active flags as well as
       the existing moderated/unmoderated.  This file currently looks
       something like:
	flags
	newsgroup	description
	newsgroup	description
	flags
	newsgroup	description
	....
    3) When a system receives a checkgroups header, it first saves the body
       in NEWSDIR/newsgroups.<authority> (or, perhaps better, "<authority>.ng")
    4) A new newsgroup file is created by catting together all of the .ng
       files (with some munging to get rid of the flags).
    5) The active file is compared against the ".ng" files (more or less
       the same way as now).
    6) There should be a config option to indicate whether the newsgroup
       update should be performed or the differences just mailed to the
       administrator.  T'would be nice to parameterize a bit further so
       that checkgroups will apply updates automatically in some hierarchies,
       but not in others.
    7) There should be a "synchronization" mechanism, so that you can create
       "ng" files for given hierarchies with your existing newsgroup set.
       This is to simplify being able to tell checkgroups about local
       groups or groups that don't have an "authority" (probably alt).

Things to think about:
	- If we extend the permissible flags, we might have to define some
	  semantics about converting C-news ones into B-news ones (at least,
	  converting it into something that B-news supports).  For example,
	  the "=newsgroup" mechanism in C-news could be used to automatically
	  update the newsgroup aliases file in B-news.  (These aren't isomorphic
	  flags, but they're reasonably close)
	- How do we implement this so as to not blow out all of the machines
	  that don't upgrade?  We keep telling them about how to disable
	  checkgroups.  (null out the shell script)
	- installation is easy - both B-news and C-news should be able to
	  slip in a shell program that implements this without changing
	  any code (B-news may need to be modified to stuff the checkgroups
	  argument out to the shell script)
      
Benefits:
	- we get automated checkgroups without the software screaming like
	  it does now.
	- we get the newsgroups[s] files updated.
	- This can be retrofitted to existing news systems easily, since
	  it's largely an independent shell script.
	- some level of parameterization to customize how it operates
	  on a finer basis.

The principle problem to be overcome is security....
-- 
Chris Lewis,
clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis
Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada)
**** somebody's mailer is appending .bitnet to my From: address.  If you
see this, please use the address in the signature, and send me a copy
of the headers of the mail message with the .bitnet return address.  Thanks!