[NNTP] Large article numbers extension

[Steve Walker]

Charles Lindsey wrote:

>In <20050726145938.GA20716 at finch-staff-1.thus.net> "Clive D.W. Feather" <clive at demon.net> writes:
>
>  
>
>>So now we're down to one basic situation: how to report a group with large
>>article numbers in GROUP, LISTGROUP, LIST ACTIVE, and NEWGROUPS. Here is
>>what I would propose:
>>    
>>
>
>  
>
>>* If the client has not used the BIGNUM command, the server acts as if
>> the high water mark is 4294967295, except that NEXT fails with 401 BIGNUM
>> instead of 421 ("no next article").
>>* If the client *has* used the BIGNUM command, article numbers greater than
>> the current {MC} are prefixed with a tag (e.g. a plus sign) to indicate
>> that they are too big.
>>    
>>

It doesn't matter what the client can support.  If the numbers can't 
roll over they have no choice but to exceed 32 bits.  It's pointless 
trying to tell the client that it's broken.

Steve.

>
>  
>
>>Thoughts?
>>    
>>
>
>The chief problem is that the old client will *never* be able to read the
>recent articles in the overflowed group. That is not good.
>
>How does that compare with the alternatives?
>
>1. Wrap-around.
>
>The client would get mightily confused. But, after a while, all the
>articles prior to the wrap would have expired, as which point we are back
>to the present situation. At that point, the client would be able to read
>the group normally. Not good, but surely better than *never* seeing
>articles in the group again.
>
>2. Have a flag day.
>
>Has anyone actually looked into how a flag day would be organized?
>
>Presumably the server goes off line for a few hours while it renumbers all
>the articles in the affected group, starting from 1 (or perhaps from
>some large constant).
>
>What does the client see when it comes back? Presumably its .newsrc file
>is all wrong. Somehow it has to reset that line of its .newsrc file, at
>which point it will be offered all the already-read articles in the group
>as it they were new. Tedious, but manageable, and no articles are lost.
>And with a bit of assistance from the server (for example, a list mapping
>old numbers to new ones, or making the new numbers differ by a large
>constant from the old ones, or keeping the old group around in a renamed
>form, with Xref headers of old articles pointing to both groups) things
>could be made almost tolerable.
>
>  
>