Re: mvgroup and extensibility

New Message Reply About this list Date view Thread view Subject view Author view

From: G. James Berigan (usefor@war-of-the-worlds.org)
Date: Fri Nov 12 1999 - 09:20:28 CST


chl@clw.cs.man.ac.uk (Charles Lindsey) wrote:
>"G. James Berigan" <usefor@war-of-the-worlds.org> writes:

>> Okay, but there's still the merge syntax to consider:

> I think you are confusing two issues here. We are not currently planning
> any variety of mvgroup that implies a merging, because everybody says the
> implementation is so horrendous that noone will ever do it. So at the
> moment, all our draft says is that, in a simple mvgroup, if both groups
> already exist, it is sufficient to rmgroup one and create the other (old
> articles remain in whichever group they were already in; all new articles
> go to the new group). It says you MAY try to merge them if you know how,
> but threatens you with the most horrible MUSTs if you get it wrong :-( .

I also note that it also fails to differentiate between right and wrong
ways to do it.

I recall some people last year thought the proper method would be to
shuffle the articles together so that overall chronological order was
preserved. I don't know what they were smoking to think that, but I
certainly don't want them smoking it anywhere near me!

>> mvgroup old.groups.* new.group moderated

> So let us just consider the simple case where you are trying to rename a
> simple group and make it moderated at the same time. The alternatives
> would appear to be:
>
> 1. moderate the oldgroup first (with newgroup). then mvgroup

Race condition: If the mvgroup arrives first, you end up recreating a new,
empty oldgroup as moderated when the newgroup arrives. Certainly an
undesirable result.

> 2. mvgroup first, then moderate it.

Race condition: If the newgroup arrives first, then the mvgroup, because
of the dire warnings against implementing any kind of merge, the articles
of the oldgroup aren't going to be moved, giving an empty newgroup. Also
an undesirable result as you lose the benefit of issuing mvgroup instead of
rmgroup.

> 3. Do both together, with some special syntax.
>
> You are proposing (3), with a 'moderated' flag. Fair enough, but how then
> do you do the reverse operation (renaming a moderated group, and at the
> same time unmoderating it)? We do not have an 'unmoderated' flag (I put
> it in, and was told to take it out.

I'd stick to my guns and put it back in. We have a case now where we
require it, and it doesn't necessarily affect the syntax of newgroup.

> NOTE: I would certainly expect the default situation for a simple mvgroup
> message to be to leave the moderation status as it was.

I agree. That's why we need flags to identify when this is not the case,
moderated _and_ unmoderated. Rare does not equal impossible, nor is rarity
a justification to make the rare impossible.


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.