From: Curt Welch (curt@kcwc.com)
Date: Tue Aug 28 2001 - 14:14:25 CDT
"Clive D.W. Feather" <clive@demon.net> wrote:
> Removing the old group immediately has problems.
Sure, but there are solutions to those problems which enable
the mvgroup to be done without this weak specifications of
a delay. All I'm saying is that I think the design I
outlined which does not include the delay is a better
way to do it.
> The message has two actions, with a delay between them.
> That's better and more robust that relying on two separate
> messages.
I don't see it that way. When you issue a command, you want
predictable results. The less prodictable the results of your
command, the less useful the command is. Two separte messages
with well defined behavior is better in my eyes that one message
with the undefined delay.
> > But, I can tell you for sure that no matter what goes in
> > the draft or the standard, my server will never treat a
> > mvgroup as anything other than a "newgroup" alias.
>
> Why ? Why are you unwilling to make the old group clearly
> *be* an old group, even if you object to the delayed
> remove ?
The delay is a minor issue with the design. That has
nothing to do with how I run my server.
The big issue I have for _my_ server is that I don't give
remote users the power to edit my group file. That's just
the way I do things.
> > However, I will NEVER remove a group, block posting to a
> > group, or cause articles to be posted elewhere, simply
> > because I received a control message asking me to do that.
> > The abuse potential is way too high.
>
> Most hierarchies have security measures in place for
> these control messages. Nobody is suggesting that they
> wouldn't apply equally here.
Ok, that's fine. My server doesn't happen to support those
so I don't think about them or keep up to date with what's
going on there.
> > My server creates
> > groups automatically for all new groups (not just newgroup
> > control messages, but anytime it sees an article posted to
> > a group which doesn't yet exist).
>
> Sheesh. In other words, you're one of the causes of the
> misspelled groups that go flying around the place.
Nope. Just the opposit. My server may be the only one in
the world which blocks peolple from posting to groups which
don't exist. All the other severs I know about let you
cross post to non-existent groups as long as you spell at
least one of the group names correctly. My server on the
other hand forces you to spell every group name correctly
or else the post is rejected.
Same thing for my newsreader (the web-based newsreader.com).
It will not let you post a message unless all the groups
you list are valid groups on the server and for new messages
(not follow-ups) you have to subscribe to all the groups
before you can post to them as well.
> If people didn't do that, then messages with spelling
> errors in the header wouldn't propogate very far.
Exactly. I stop it where it should be stopped, at the point
of injection. If all the other servers on Usenet were as
good as mine in that regard, spelling errors in the
Newsgroups line wouldn't be the problem that it is today.
> Posters would soon figure out that the message isn't
> going to the group desired, and would adjust the name
> accordingly.
They don't "soon" figure out anything if they aren't told
about the problem when they hit the "post" button. You
never want the tranist servers to be doing stronger
checking than the injection servers are doing because
propigation problems are something the user can't easilly
see, understand, or fix.
> With this autocreate bogosity, other people find
> themselves thinking that the group is legitimate. That
> means it hangs around for longer.
That's true. The autocreate logic does have some drawbacks.
But the autocreate isn't the source if the problem as long
as you don't autocreate on post. And I don't. I autocreate
on transit or on newgroup messages.
> > And it automatically
> > removes groups when the articles have expired and the group
> > has seen no new traffic for an extended period of time.
>
> Even moderated groups ?
I have the ability to mark a group with a special "keep"
flag which will prevent it from ever being removed. But
right now the server will auto delete moderated groups if
they are not marked that way, and you are right, that's a
problem because it could cause a very low volume moderated
group to transfrom to un-moderated status on it's own. I
hadn't even thought about that issue. I should take care
to either mark all the moderated groups as "keep" groups,
or simply run a regular script to check and update the
list of moderated groups.
Personlly, moderated groups is somthing else on my list
of things that no longer belong on Usenet.
> So a low-traffic group will keep appearing and
> disappearing, and during the off time your users won't
> know it's there ? Instead they'll just create new groups
> with names not quite the same as the one they
> mis-remembered ?
No, not really. First, groups don't come and go that
quickly. How long it takes to be deleted is a function of
the current high article number. A group that's only seen
5 posts total will vanish much quicker than a group which
has seen 10,000 in it's life for example. So groups that
are valid and have been around a long time, will tend to stay
around even if they go though mulitple months of no traffic.
I think they have to be idle for something like 6 months before
they would be deleted.
And even a bogus group with a single post to it created by
one user's typo, will last for as long as the post remains
on the server (weeks for my server).
And my users don't have the direct power to create groups
on my server. They can't post to the group if it doesn't
exist, so they don't tend to just take a guess at a group
name and try it. So the problem of new groups constantly
being created with slight variations of the old names
just isn't a problem which is caused by my users.
> Yet you're unhappy to block the "old" group in a move,
> so that it can die away more quickly ?
No no no. You misunderstand my motivation. I have no
problem blocking a group in a move. What I have a problem
with is spending the time it takes to keep track of what's
going on in all the groups. 10 years ago, when Usenet
was less than 1000 groups, it took a lot of work to keep
up with all the "newgroup" issues and help keep a "clean"
active file. I used to do that. I spent a lot of time
trying to run a "good" server.
I just feel that time has passed.
Granted, we have tools to allow this to still work. Like
PGP signed control messages. So now instead of keeping track
of all the groups, an admin just has to make sure he has a
valid and current set of PGP keys. These tools and others
allow things to continue to work. But for me, that's just
something I feel I don't need to spend my time on anymore.
So I created a server which simply indexs all the news it
receives. Now if we could just get rid of these moderated
groups, then everything would be great. :)
> > If you want to rename a group, just create the new group
> > and get everytone to switch to the new group. Once everyone
> > has switched, send out the rmgroup.
>
> Experience shows this is not ideal. A specific "don't
> use the old group any more" process would help, rather
> than relying on people to "get the word".
I haven't watched a lot of these happen, but in general, I
think the real problem is two fold. First, there's the problem
that not all servers create the new group. If a user on
that server only sees the old group, and not the new one,
then of course he's going to post to the wrong place. My
autocreate logic would solve that problem if it became the
"norm" on Usenet. If newgroup isn't working for a server now,
mvgroup isn't likley to fix the problem in the future.
Second, when a group rename doesn't work well, I suspect it's
because there wasn't a clear concensious that it should happen.
if that's the case, then the rename is never going to work
well. Some people will continue to use the old group (or
encourage their users to use the old group) just out of protest.
If you want to get the word out about not using an old group,
then the best way to do it is to simply post a message to
that group on a regular basis (say weekly), which tells people
not to use the group anymore. If people continue to post
in the group after that, then who cares. If they want to
hang out in the old room after the crowd left, then let them
do it. All the "real" posters are over in the big room.
At least that's how I see it.
> news != Usenet
news == USENET. It's wrong to think of it otherwise.
If people want to use Usenet technology for other reasons,
(like local private groups etc), then that is fine. And if
people want to add functions to usenet servers to help them
do that, then that too is fine. But anytime you talk about
changing standards, you have to first make sure it works
for Usenet.
mvgroup in any of it's forms has value for people that are
willing to try and make a group rename happen, and I don't
see that it would cause any real problems either. So if
people want to add it the standard I'm not going to try
and stop it.
> And Tale looks rather like a central authority to me. As
> does the UK Committee, and Dave Williams for demon.*,
> and ....
LOL. So that's 2 kings, one commitee, and one "...". Oh,
yeah, that's a central authority. No doubt about who's in
charge there. (I do understand you are talking about each
controling their own hierachy so the idea isn't as foolish
as my reply would indicate, but still, there's very little
real central control of usenet and your statement above just
demonstrates that to me).
> > Merging articles? Like that's going to happen. Good laugh.
> If it were practical, there would be obvious benefits.
> Which is a reason to talk to server authors.
Yeah, the idea is worth talking about. But after 10 seconds
of thought I decided it was wrong. Not only is it very hard
to do on most servers, it causes all sorts of complex
end-user issues (like didn't I just read all these messages
over in group x.y? Why am I seeing 3 months of messages
again here?)
> > The initial message (application/news-tranmission) stuff is
> > likewise a stupid thing to do. It totally breaks all the
> > current spam filters and feed file logic.
>
> Hmm. Interesting point. But, there again, newgroups get
> authenticated elsewise, so there shouldn't be a spam
> problem.
True, if you have authentication working, then that's not
going to be a big problem.
But from my perspective, all this is just adding more and
more complexity to Usenet and creating more and more work
for me (and all the usenet admins). With the continued
growth of usenet, what we need is not more complexity, but
less. Which is why I've gone to a system of autocreating
newsgroups.
Usenet is not an edited publication. Why do we feel such a
strong need to set up commities to edit and control the
newsgroup names when we don't do the same for the content?
The only reason we have done this in the past is because
of the technical limitations of the software. It was
because the act of creating a news group on usenet required
something special to happen on all the servers (i.e. the group
had to be added to the active file, and new directories had
to be created etc). It was also because the servers (and
the protocols) have real limitations on how many groups they
can deal with - so it represents a scarce resource that needs
to be allocated.
But in todays world where search engine technology exists
that is able to cross index every word in every page on the
entire web (or at least huge portions of it), why can't we
build news servers that can do the same for just the
newsgroups line? And then we can drop most the control
messages, and the commites which try to control them, and
simply let the users post wherever they want.
Sure, this would create problems. The number of groups
would grow by orders of magnatude. LIST ACTIVE would stop
being useful in it's current form.
But these problems have solutions. If you design the
servers from the ground up to deal with large numbers of
groups, then it's very doable. And you can create a LIST
ACTIVE command which allows the user to list groups based
on the amount of traffic (like show me only the top 1000
groups or only groups with more than X number of messages
in them etc).
My point with all this is that mvgroup is an attempt to make
group administration work better when the real problem here
is that we shouldn't be trying to adminster the groups in
the first place. And if you are going to try and change
Usenet, then I think the correct direction to head in is
one of less group administration, and not more.