On 4 Nov 2019 14:22:20 GMT, Frank Slootweg wrote:

[big snips ahead, because it's mostly stuff that I agree with and some
other stuff that I'm not addressing in this post]

Apparently TB currently uses the newsrc file only for recording the
subscribed groups, *not* for recording the article numbers of the read
articles in those groups.

See Tools - Account Settings - your News account - 'Server
Settings' - Message Storage - newsrc file: - Browse...

You will see one or more server.rc files with entries like:

alt.comp.os.windows-10:

which means you're subscribed to that group.

A *normal* (non-TB) .newsrc file would have:

alt.comp.os.windows-10: 1-37201,37225,37231,37233-37235

which means I've read all articles with the indicated ranges and
numbers.

I.e. I've *not* (yet) read articles 37202-37224, 37226-37230 and
37232.

Why TB can't be bothered to do this properly is anyone's guess.

Hmmm, that's very interesting. Are you sure that your .newsrc file is
indicating which articles you've read?

My experience is limited to Agent, which has always touted itself as being
fully compliant with standards, (and why wouldn't they), but with Agent the
..newsrc file only tells me a few things.

1. Contains a list of all available newsgroups available at this server,
one newsgroup per line, ending with a blank line to indicate EOF. My
current server, Newshosting, carried 110,673 groups as of my last refresh,
so my .newsrc file for this server is 110,674 lines long.

2. Shows me which groups are currently subscribed (: versus !)
Subscribed groups are moved to the top of the list.

3. For any group for which I've ever retrieved headers, (whether currently
subscribed or previously subscribed), it tells me the server-specific
article numbers that have been retrieved, shortening the list to a range
(x-y) when possible, otherwise using a comma separated list.

That's all, nothing else. No Message IDs, no read/unread status. No
additional fields of any kind.

Does your .newsrc tell you more than that? If so, the whole notion of
sharing a common .newsrc file across multiple newsreaders is in jeopardy.
Not that I share a common .newsrc, but I always assumed that I could.
That's essentially why it was created, after all.

One .newsrc file for all the groups subscribed on a particular
News server.

For all of the groups that are available at that server, not just the
groups that are subscribed.

A .newsrc file only records *ranges* of article numbers, with the
occasional not-yet-read article numbers.

I would change "not-yet-read" to "not-yet-retrieved".

There is no requirement that news servers create and assign article numbers
in sequential order. They usually and normally do, but Easynews (for
example) used to be notorious for creating articles out of order. Agent,
and I presume other newsreaders, has the capability to deal with that
through a configuration setting.

In Agent, for each configured server, you get an opportunity to declare
that this "Server creates messages out of order." By checking the box,
you're telling Agent not to assume that the highest article number means
that everything before that has been retrieved.

There's also an edge case that a certain Dutch dump group presented quite a
few years back. That group got so much traffic that news servers were
forced to roll over the article numbers, starting again at the beginning.
Newsreaders were generally unprepared for that and marked everything as
retrieved, thus making tons of posts 'disappear'. The Easynews support
group was awash with support requests when that happened. Folks who had
configured their newsreaders to expect article numbers to be retrieved out
of order didn't suffer when the article numbers rolled over. Everyone else
did. (Full recovery was always possible, of course.)

A typical entry/line is well less than 80 characters. *Some* entries/
lines might be a few hundred characters long, during the time you have
not yet completely 'catched up' with the group.

For example, my .newsrc file is 2574 bytes, 94 lines, i.e. a little
over *27* characters per entry (including LF).

As a second data point to reinforce your position, my Newshosting .newsrc
file is currently 3,008,221 bytes, 110,674 lines (one line per group plus a
trailing blank line to show end-of-file). The longest line is 14,211
columns, but the second longest is just 85 columns and every line after
that is less than 45 columns. All in all, this would be extremely easy to
parse, if desired.

Believe me, the structure, 'size', 'slowness', etc. of a .newsrc file
is a complete non-issue. It wasn't an issue on 640KB machines and it
surely isn't now.

I totally agree.

If a newsreader can handle getting articles from multiple News
servers, then there's a .newsrc file per server. Handling multiple
servers is of course more complex, but several newsreaders handle this
functionality in a seamless way. (AFAICT, TB can handle multiple News
servers, but without any integration, i.e. if you're subscribed to the
same newsgroup on multiple servers, you'll see each article multiple
times.)

That's why Agent uses a separate database for its Crosspost Management
function. The .newsrc file(s) aren't suitable substitutes since they:
1. Don't show read status.
2. Don't include Message IDs.
3. Only show server-specific article numbers.

The newsreader would have no way of knowing that article X on server A is
the same as article Y on server B if all it had to go on is the article
number. So .newsrc file(s) are useless for crosspost management.

FWIW, I use a local,'small', 'personal', News server (Hamster) to -
amongst others - get the same - multi-server - functionality. Hamster
sits between my newsreader (tin) and my NSP (News SP),
News.Individual.[DE|.NET]. To my NSP, Hamster looks like a newsreader.
To my newsreader, Hamster looks like a News server.

That's good to hear. I used to hear a lot of Hamster stories in the early
2000's, but not so much anymore. Same with Stunnel stories. I used Stunnel
for a period of time, but never Hamster. I'm familiar with it, though.