From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Tue Aug 07 2001 - 05:45:25 CDT
In <200108062252.SAA26656@darkstar.prodigy.com> davidsen@prodigy.com (Bill Davidsen) writes:
>I am a realist. The servers who don't remove the old groups by hand are
>not going to remove them by magic, either. That's because they either
>have a policy of not removing a group with traffic, recreate a group
>with traffic, or are run by people who inherited news when the person
>who installed it left.
I reckon there are very few sites that reject rmgroups because of a policy
that "rmgrouping is a form of censorship", or somesuch. I expect it
happens more often because the software came configured that way (as it
certainly did before PGPverify) or because it was once done that way and
nobody has bothered to change it (or the person has left, as you say).
But if new software comes with 'mvgroup' implemented (even if only in a
rudimentary form), and defaults set to honour it (assuming it PGPverifies
OK perhaps), then sites upgrading to the new software will likely go along
with it. One expects that quite a lot of sites will want to upgrade as soon
as implementations conforming to the new standard become available.
>>
>> 1. Would it be a useful feature to have, assuming it worked?
>Yes, but that's a big assumption.
OK, we seem to be getting agreement on the desirability part.
>> 2. Can it (or is it likely to) be implemented on a timescale that would
>> ensure it would be regarded as normal practice in a few years time?
>As proposed, I doubt it in less than a decade. If you just require that
>a new group be created and the old one marked no-posting, maybe. Or than
>posts be marked with Follow-up on posting. Or anything other than moving
>old posts.
Well I have suggested more or less that in reply to Russ. Here is a more
concrete idea of what it might be like:
1. 'mvgroup' means do a newgroup plus a rmgroup.
2. The actual rmgroup part SHOULD be deferred for a reasonable period
(between 1 to 30 days, though I would not want to specify precise figures)
to allow articles in transit and from injectors not yet upgraded to
continue to arrive.
3. Perhaps local posting to oldgroup to be stopped immediately ('n' in
active file in some implementations). That might be at the MAY/Ought/NOTE
level.
4. Perhaps retention of articles after the (deferred) rmgroup until they
expire ('x' in active file). That is certainly NOTE level I think, though
it is common current practice.
5. New articles arriving for oldgroup (and even existing articles in
oldgroup) MAY be placed in (or transferred to) newgroup ('=newgroup' in
active file).
6. In a NOTE, explanation that the MAY is because existing systems are
unlikely to offer this feature (at least for some time), but with some
encouragement to move towards that goal (perhaps even threaten MAY->SHOULD
in a future standard). Also a warning that such merging may never be
possible if both groups exist already and both contain articles.
7. In a NOTE, warning that the effect of 5 could be that the newsgroups
listed in the Xref header might include oldgroup or newgroup or both.
8. In addition, I would propose to remove the present idea of 'mvgroup
comp.foo.* comp.bar.*' since it does not scale well if implemented as a
loop doing all the implied individual mvgroups (the hierarchy admin can
always issue those individual mvgroups, preferably in small batches, if he
really needs to do that sort of thing).
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clw.cs.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5