Article 12345 unavailable: numbers not in sync

Martin Trautmann <[email protected]>
Newsgroups gmane.network.slrn.user
Message-ID <[email protected]>
Hi all,

since there's much more activity within the slrn development again, I'd 
like to ask for another improvement.

I do use a flawed news server setup here. slrn tells me many times:

   Article NUMBER unavailable

This might indicate that the article is no longer kept on this server. 
But that's not true.

When I change to ANOTHER usegroup and call this article via its message 
id, it's no problem to call this posting. When I try this within the 
newsgroup itself, it does not work, since this seems to fall back on the 
attempt to catch the number again.

The reason is known: There's just one news server name (news.nexgo.de). 
However, the requests are spread to different servers, such as

Xref: newsspool4.arcor-online.net GROUP:NUMBER

These different servers are not in sync and use different numbers.

Example: slrn tries to get de.comm.software.newsreader:103534 which is
Message-ID: <[email protected]>
Subject: Re: Weiterentwicklung von slrn
References: [...] 
<[email protected]>

This worked this time. Now I want to get the previous one,
<[email protected]>

Xref: newsspool4.arcor-online.net de.comp.hardware.cpu+mainboard.amd:109604
   de.comm.software.newsreader:103533

... and slrn might tell me:
   Article 103533 unavailable

This happened since a different server would reply which would use the 
number such as 456777 for this posting instead.

I don't know whether there's any RFD that would specify how different 
news servers behind one address should ensure that there message numbers 
always would be in sync.

Concerning slrn, I'd welcome any improvement that would permit a 
fallback solution which would try another method once again if the call 
by message number would fail - probably not relying on xover headers 
only. It should be ensured that the list of read postings in .jnewsrc 
does use the proper number only.

Thanks!
Martin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.