For cross-posts, is there any way to automatically mark the message read
in the other groups its posted to once I read it?
Check your newsreader's settings. Otherwise you'll have to ask in the betterbird developer's support forum.
Yes AFAIK. Which newsware are you using?
Hi,
For cross-posts, is there any way to automatically mark the message read
in the other groups its posted to once I read it?
--
user <candycane> is generated from /dev/urandom
On 10/8/23 03:31, Adam H. Kerman wrote:
Check your newsreader's settings. Otherwise you'll have to ask in the >>betterbird developer's support forum.
I looked, couldn't find anything in settings.
https://groups.google.com/g/mozilla.support.thunderbird/c/S5tSRiGR0w8
Seems that the solution proposed is "use filters and check cross posting >manually" which kinda sucks. It almost makes me want to switch to Claws,
but that one is broken too (doesn't display newsgroup list in subscribe
menu)
What happens if you start with a fresh profile rather than importing
your Thunderbird profile?
betterbird.eu
For cross-posts, is there any way to automatically mark the message read
in the other groups its posted to once I read it?
Rather than search across many subscribed newsgroups, the client could
use the Xref header, if present, to determine in which newsgroups a
message got cross-posted.
That would shorten the time for "mark as read" to find the other copies
of the message.
A problem noted there is that the client may not yet have populated the
other newsgroups into which a message got cross-posted. The "mark as
read" action would be stalled by however long it takes for the client to retrieve all messages (well, those that cover the cross-posted article)
in the Xref newsgroups before they could also get marked as read.
VanguardLH <V@nguard.LH> writes:
Rather than search across many subscribed newsgroups, the client could
use the Xref header, if present, to determine in which newsgroups a
message got cross-posted.
Indeed, this is what essentially every client does and what they should
do.
A problem noted there is that the client may not yet have populated the
other newsgroups into which a message got cross-posted. The "mark as
read" action would be stalled by however long it takes for the client to
retrieve all messages (well, those that cover the cross-posted article)
in the Xref newsgroups before they could also get marked as read.
The client shouldn't have to retrieve articles to mark them as read. The standard representation on the client that goes all the way back to the
very early days of Usenet is called a "newsrc". It holds a list of groups (often both the unsubscribed and the subscribed groups so that read
articles are tracked properly if someone later subscribes to the group)
and a list of read articles by number in each group. In text form, it
looks something like this:
rec.arts.sf.misc! 1-14774,14786,14789
Russ Allbery <eagle@eyrie.org> wrote:
The client shouldn't have to retrieve articles to mark them as read. The
standard representation on the client that goes all the way back to the
very early days of Usenet is called a "newsrc". It holds a list of groups >> (often both the unsubscribed and the subscribed groups so that read
articles are tracked properly if someone later subscribes to the group)
and a list of read articles by number in each group. In text form, it
looks something like this:
rec.arts.sf.misc! 1-14774,14786,14789
Does Thunderbird currently store the article numbers of messages in its
MSF database files?
I don't recall Tbird uses .rc files
Except that only tells you (the client) in which newsgroups an article
was cross-posted. You would still need the Message-ID value to find the matching article in each of those newsgroups. Searching takes time.
Does Tbird poll all newsgroups, and retrieve all new message in every
one (shown as a folder in the tree pane)? Or does it poll a newsgroup
only when the folder (newsgroup) is selected in the tree?
VanguardLH <V@nguard.LH> writes:
Except that only tells you (the client) in which newsgroups an article
was cross-posted. You would still need the Message-ID value to find the
matching article in each of those newsgroups. Searching takes time.
If a news reader needs the message ID to mark an article as read, it's
doing something fairly odd.
* VanguardLH wrote:
Russ Allbery <eagle@eyrie.org> wrote:
The client shouldn't have to retrieve articles to mark them as read. The >>> standard representation on the client that goes all the way back to the
very early days of Usenet is called a "newsrc". It holds a list of groups >>> (often both the unsubscribed and the subscribed groups so that read
articles are tracked properly if someone later subscribes to the group)
and a list of read articles by number in each group. In text form, it
looks something like this:
rec.arts.sf.misc! 1-14774,14786,14789
Does Thunderbird currently store the article numbers of messages in its
MSF database files?
Not in the MSF files, but in the *.rc files.
I don't recall Tbird uses .rc files
From my news.eternal-september.org.rc file: --------------------------------------------
eternal-september.config: 1-958
eternal-september.grouprequests: 1-690
eternal-september.info: 1-64
eternal-september.moderated: 1-27,29
eternal-september.newusers: 1-1366
eternal-september.nocems: 1-27
eternal-september.talk: 1-1515
eternal-september.test: 1-10382,10397,10502,10503,10544,10546-10548 eternal-september.where.are.all.the.newsgroups: 1-2
control.checkgroups: 1-1649
control.newgroup: 1-875
control.rmgroup: 1-865
alt.de.test: 1-6609
uk.d-i-y: 1-1261447
eternal-september.support: 1-15165,15204-15209,15434,15438,15448-15450
This is what Russ was talking about and I can confirm that marking
a crossposted article as read in one group (or simply opening it)
also marks the article as read in all groups it was crossposted to.
It has been like that for more than 15 years, IIRC.
On 10/14/23 05:32, VanguardLH wrote:
Does Tbird poll all newsgroups, and retrieve all new message in every
one (shown as a folder in the tree pane)? Or does it poll a newsgroup
only when the folder (newsgroup) is selected in the tree?
You can set it to poll every x minutes and/or when you boot up TB. It
does always poll when you open a folder, I believe.
Ray Banana <rayban@raybanana.net> wrote:
* VanguardLH wrote:
Russ Allbery <eagle@eyrie.org> wrote:
The client shouldn't have to retrieve articles to mark them as read. The >>> standard representation on the client that goes all the way back to the >>> very early days of Usenet is called a "newsrc". It holds a list of groups
(often both the unsubscribed and the subscribed groups so that read
articles are tracked properly if someone later subscribes to the group) >>> and a list of read articles by number in each group. In text form, it >>> looks something like this:
rec.arts.sf.misc! 1-14774,14786,14789
Does Thunderbird currently store the article numbers of messages in its
MSF database files?
Not in the MSF files, but in the *.rc files.
I don't recall Tbird uses .rc files
From my news.eternal-september.org.rc file: --------------------------------------------
eternal-september.config: 1-958
eternal-september.grouprequests: 1-690
eternal-september.info: 1-64
eternal-september.moderated: 1-27,29
eternal-september.newusers: 1-1366
eternal-september.nocems: 1-27
eternal-september.talk: 1-1515
eternal-september.test: 1-10382,10397,10502,10503,10544,10546-10548 eternal-september.where.are.all.the.newsgroups: 1-2
control.checkgroups: 1-1649
control.newgroup: 1-875
control.rmgroup: 1-865
alt.de.test: 1-6609
uk.d-i-y: 1-1261447
eternal-september.support: 1-15165,15204-15209,15434,15438,15448-15450
This is what Russ was talking about and I can confirm that marking
a crossposted article as read in one group (or simply opening it)
also marks the article as read in all groups it was crossposted to.
It has been like that for more than 15 years, IIRC.
If all that were doable in other e-mail clients, seems inane that Tbird hasn't accomplied the same feat for a 22-year old bug ticket. Comes
back to me thinking Tbird was first designed to be an e-mail client, and newsgroups got tacked on.
Like you (and Ray), I don't use Thunderbird as my regular newsreader,
so it would be nice if some people who *do* use Thunderbird on a regular basis, can confirm if this alleged 'bug' - Thunderbird does (sometimes)
not mark crossposted articles as read - exists at all or that it's just
and urban legend, FUD, etc..
On 10/15/23 07:34, Frank Slootweg wrote:
Like you (and Ray), I don't use Thunderbird as my regular newsreader,
so it would be nice if some people who *do* use Thunderbird on a regular basis, can confirm if this alleged 'bug' - Thunderbird does (sometimes)
not mark crossposted articles as read - exists at all or that it's just
and urban legend, FUD, etc..
It usually doesn't work, but lately I haven't noticed it.
So the questions stands: What do *Thunderbird* users experience?
Hi Frank,
So the questions stands: What do *Thunderbird* users experience?
As a user of Thunderbird, and reading both news.software.readers and >news.software.nntp, I confirm that when I read (and mark as so) an
article in this thread either in news.software.readers or
news.software.nntp first, it still shows up unread in the other newsgroup. >I'm using the latest version of Thunderbird (115.3.2), and this bug was >present in previous versions too.
My .rc file is named "newsrc-servername" (newsrc-news.trigofacile.com)
and seems normal, but not updated when a crossposted article is read in
one newsgroup.
As a user of Thunderbird, and reading both news.software.readers and news.software.nntp, I confirm that when I read (and mark as so) an
article in this thread either in news.software.readers or
news.software.nntp first, it still shows up unread in the other newsgroup. I'm using the latest version of Thunderbird (115.3.2), and this bug was present in previous versions too.
My .rc file is named "newsrc-servername" (newsrc-news.trigofacile.com)
and seems normal, but not updated when a crossposted article is read in
one newsgroup.
From RFC 2980, section 2.1.7, the 'list overview.fmt' shows the overview headers that get sent by the server. Both ES, and my server
(individual.net) show "Xref:full". Do any NNTP servers not add this
overview header to a retrieved article? The same RFC says "Many
newsreaders work better if Xref: is one of the optional fields." I
never thought of it as an optional header.
https://www.rfc-editor.org/rfc/rfc5536.html#page-24 describes the syntax
of the Xref header, but that section 3.2.14 is under section 3.2 which
is titled "Optional Header Fields". Maybe the Xref header has become ubiqitous in Usenet, but it is an optional header. What happens when a client that relies on Xref (and .rc files) hits an endpoint server that doesn't add Xref when the client retrieves an article?
Maybe that's why the Tbird devs didn't want to rely on an optional
header.
If indeed Thunderbird doesn't mark crossposted messages as read in all
groups (it sounds from the recent messages like it doesn't, but I don't
use it so I don't know), another possibility is that this was an
intentional design choice. Thunderbird is primarily a mail reader, [...]
As a user of Thunderbird, and reading both news.software.readers and news.software.nntp, I confirm that when I read (and mark as so) an
article in this thread either in news.software.readers or
news.software.nntp first, it still shows up unread in the other newsgroup.
I'm using the latest version of Thunderbird (115.3.2), and this bug was present in previous versions too.
Hi Frank,
So the questions stands: What do *Thunderbird* users experience?
As a user of Thunderbird, and reading both news.software.readers and news.software.nntp, I confirm that when I read (and mark as so) an
article in this thread either in news.software.readers or
news.software.nntp first, it still shows up unread in the other newsgroup. I'm using the latest version of Thunderbird (115.3.2), and this bug was present in previous versions too.
My .rc file is named "newsrc-servername" (newsrc-news.trigofacile.com)
and seems normal, but not updated when a crossposted article is read in
one newsgroup.
But to be sure:
In the above mentioned context, are you reading both groups from the
same server? (Or better yet, perhaps you have configured only one server
in Thunderbird?)
The reason for my question is obvious: Thunderbird should use article
numbers to mark articles are read in both groups, but (as you are of
course all too aware of), article numbers are server specific, so
marking crossposted articles are read across multiple servers is
(nearly) impossible.
Neither do I, but it's just SMOP (Small Matter Of Programming). All
you have to do is to remember all the hundred of thousands / millions of message-ids of the postings you've ever 'read'. How hard can *that* be!?
:-)
Thus spake Frank Slootweg <this@ddress.is.invalid>
The reason for my question is obvious: Thunderbird should use article numbers to mark articles are read in both groups, but (as you are of
course all too aware of), article numbers are server specific, so
marking crossposted articles are read across multiple servers is
(nearly) impossible.
Obviously, I was referring to a setup where all groups are read from the
same server.
It would have never occurred to me that somebody would expect this to
work across multiple servers ;-)
I don't know any newsreader that is able to do that.
On 10/16/23 10:49, Frank Slootweg wrote:
Neither do I, but it's just SMOP (Small Matter Of Programming). All
you have to do is to remember all the hundred of thousands / millions of
message-ids of the postings you've ever 'read'. How hard can *that* be!?
:-)
You could just scan for matching ids when you read an article. Or, maybe
you could limit it to the messages read in the last x days, to cut down
on processing time.
On 2023-10-16 18:03, candycanearter07 wrote:
On 10/16/23 10:49, Frank Slootweg wrote:
Neither do I, but it's just SMOP (Small Matter Of Programming). All
you have to do is to remember all the hundred of thousands / millions of >> message-ids of the postings you've ever 'read'. How hard can *that* be!? >> :-)
You could just scan for matching ids when you read an article. Or, maybe you could limit it to the messages read in the last x days, to cut down
on processing time.
A more practical optimization is to only retain a database of MIDs of messages that are marked "read" in actively kept message storage. Thus
when a read message is "aged out" of storage, its "read" status is aged
out too. To avoid old messages transiting in and out of view, keep a
count of how many copies are marked read for each MID and count that
down as messages age out. Once in a while, rebuild database from the
stored messages and their "read" status, then do a second pass to mark duplicates of read messages as read. Bonus: Also index the body
contents hash to catch identical multi-posting.
As a user of Thunderbird, and reading both news.software.readers and
news.software.nntp, I confirm that when I read (and mark as so) an
article in this thread either in news.software.readers or
news.software.nntp first, it still shows up unread in the other newsgroup. >> I'm using the latest version of Thunderbird (115.3.2), and this bug was
present in previous versions too.
In the above mentioned context, are you reading both groups from the
same server?
(Or better yet, perhaps you have configured only one server in Thunderbird?)
Jakob Bohm <jb-usenet@wisemo.com.invalid> wrote:
On 2023-10-16 18:03, candycanearter07 wrote:
On 10/16/23 10:49, Frank Slootweg wrote:
Neither do I, but it's just SMOP (Small Matter Of Programming). All >>>> you have to do is to remember all the hundred of thousands / millions of >>>> message-ids of the postings you've ever 'read'. How hard can *that* be!? >>>> :-)
You could just scan for matching ids when you read an article. Or, maybe >>> you could limit it to the messages read in the last x days, to cut down
on processing time.
A more practical optimization is to only retain a database of MIDs of
messages that are marked "read" in actively kept message storage. Thus
when a read message is "aged out" of storage, its "read" status is aged
out too. To avoid old messages transiting in and out of view, keep a
count of how many copies are marked read for each MID and count that
down as messages age out. Once in a while, rebuild database from the
stored messages and their "read" status, then do a second pass to mark
duplicates of read messages as read. Bonus: Also index the body
contents hash to catch identical multi-posting.
I said "hundred of thousands / millions of message-ids" for a reason.
I have well over a million articles in my "message storage". Keeping
that a amount of messages-ids is already not practical, but *scanning*
(for read/not_read status) them for each an every new (and old) article
is impossible.
But even if you don't keep (that) many articles in your message store, when you add a new newsserver which has a long retention time, you *do*
have to scan all those articles, just in case there's one which you have already marked as read.
That's why newsservers and newsreaders use article numbers instead of message-ids. It makes things much more simple (actually possible instead
of impossible). But yes, it works only for a specific server, not
accross servers and when adding a new group or/and new server you should
only fetch the latest N articles (which is very simple using article numbers).
Bottom line: Using article numbers is done for a very good reason.
All you have to do is to remember all the hundred of thousands /
millions of message-ids of the postings you've ever 'read'. How hard
can *that* be!?
On 2023-10-16 19:27, Frank Slootweg wrote:
Jakob Bohm <jb-usenet@wisemo.com.invalid> wrote:
On 2023-10-16 18:03, candycanearter07 wrote:
On 10/16/23 10:49, Frank Slootweg wrote:
Neither do I, but it's just SMOP (Small Matter Of Programming). All >>>> you have to do is to remember all the hundred of thousands / millions of >>>> message-ids of the postings you've ever 'read'. How hard can *that* be!? >>>> :-)
You could just scan for matching ids when you read an article. Or, maybe >>> you could limit it to the messages read in the last x days, to cut down >>> on processing time.
A more practical optimization is to only retain a database of MIDs of
messages that are marked "read" in actively kept message storage. Thus
when a read message is "aged out" of storage, its "read" status is aged
out too. To avoid old messages transiting in and out of view, keep a
count of how many copies are marked read for each MID and count that
down as messages age out. Once in a while, rebuild database from the
stored messages and their "read" status, then do a second pass to mark
duplicates of read messages as read. Bonus: Also index the body
contents hash to catch identical multi-posting.
I said "hundred of thousands / millions of message-ids" for a reason.
I have well over a million articles in my "message storage". Keeping that a amount of messages-ids is already not practical, but *scanning*
(for read/not_read status) them for each an every new (and old) article
is impossible.
But even if you don't keep (that) many articles in your message store, when you add a new newsserver which has a long retention time, you *do* have to scan all those articles, just in case there's one which you have already marked as read.
That's why newsservers and newsreaders use article numbers instead of message-ids. It makes things much more simple (actually possible instead
of impossible). But yes, it works only for a specific server, not
accross servers and when adding a new group or/and new server you should only fetch the latest N articles (which is very simple using article numbers).
Bottom line: Using article numbers is done for a very good reason.
You don't understand what I wrote. Idea would be to use some kind of available (search optimized) database engine to store the values,
updated incrementally as messages enter and leave the storage or are
marked read. Scanning all messages would be a "once in a while"
database repair in case the database gets out of sync with the message storage and be done using O(n*log(n)) code.
Database lookups would happen during the initial import of messages (to
see if a newly arrived message was marked read by an earlier user access
to a duplicate) and when displaying a message or its header on screen
(to see if it a duplicate was marked read since its arrival).
Thus common operations change from complexity O(n*n) to O(delta*log(n))
given typically assumed lookup costs in indexed databases.
Frank Slootweg <this@ddress.is.invalid> wrote:
All you have to do is to remember all the hundred of thousands /
millions of message-ids of the postings you've ever 'read'. How hard
can *that* be!?
There are some users that run proxy servers for personal use, like using Hamster to leech from a Usenet provider. [...]
Hard enough to implement read-state tracking on one server. Massively
more difficult to do across multiple servers. And we're talking about
NNTP clients that could be running on underpowered computers.
Read-state tracking for multiple servers can be done by aggregrating articles from several servers. I've seen people imply that some
newsreaders can do that, but I have no details (Any takers?). And, as I
said above, Hamster can do this as well. Perhaps Leafnode can do the
same on Linux (the OP uses Linux).
Read-state tracking for (not on) one server is trivial. Every
newsreader does it (via article-number range tracking in .newsrc type
files). That Thunderbird et al mess it up, doesn't change that.
Read-state tracking for multiple servers can be done by aggregrating
articles from several servers. I've seen people imply that some
newsreaders can do that, but I have no details (Any takers?). And, as I
said above, Hamster can do this as well. Perhaps Leafnode can do the
same on Linux (the OP uses Linux).
How can I... (Procedural Help)[end quote]
Almost virtual groups
There are no virtual groups in Dialog, however you can simply copy or move >articles from one group to another manually or by using an action rule: >[a.binary.group]
!move(a.binary.group;NewsserverOne) bytes %>0
All previous examples used a folder as the target of the copy/move operation. >This rule uses a newsgroup as the target. Note that the name of the target >group and the name of the newsserver where this group is from is separated by >a semicolon.
Say, you are using two newsservers named "NewsserverOne" and "NewsserverTwo". >Both newsservers have the group "a.binary.group", but while most of the >messages are the same in this group on the two servers, there are some that >are not available on the other server.
The first line in the preceding sample makes sure that the following rule is >only applied to the "a.binary.group" newsgroup.
The rule itself simply says to move all articles (since the condition "bytes >%>0" is always met) to the group a.binary.group of NewsserverOne.
If you retrieve message headers for this group from server NewsserverOne, the >rule is ignored, since all articles go to the correct group anyway. If you >retrieve message headers from NewsserverTwo for this group though, they will >not show up in "a.binary.group (NewsserverTwo)", but in "a.binary.group >(NewsserverOne)".
The result is that you joined messages from the same group, but different >newsservers into one group in Dialog. This is especially useful for binary >groups to fill missing multipart postings.
Frank Slootweg <this@ddress.is.invalid> wrote:
Read-state tracking for multiple servers can be done by aggregrating articles from several servers. I've seen people imply that some
newsreaders can do that, but I have no details (Any takers?). And, as I said above, Hamster can do this as well. Perhaps Leafnode can do the
same on Linux (the OP uses Linux).
At that point as a cross-server aggregator, using something like Hamster might suffice. It would collect articles across multiple servers, but
does Hamster then assign its own article numbers (so it could add the
Xref header with its article numbers)?
Frank Slootweg <this@ddress.is.invalid> wrote:
All you have to do is to remember all the hundred of thousands /
millions of message-ids of the postings you've ever 'read'. How hard
can *that* be!?
Thunderbird uses SQLite for the messages databases, one for each folder (newsgroup). While SQLite is fast for small database sizes, it doesn't
scale well. The bigger the database, the slow queries get, and the
slowdown is not linear. SQLite recommends once you pass into the
terabyte range to find a different solution.
https://www.dbtalks.com/tutorials/learn-sqlite/what-are-the-limitations-of-sqlite
A SQLite database can have maximum 2147483646 pages. Hence the maximum
number of tables in a schema cannot reach more than 2147483646. The
maximum number of rows in a table is 264. The maximum number of columns
is 32767 in a table.
Neither do I, but it's just SMOP (Small Matter Of Programming). All you
have to do is to remember all the hundred of thousands / millions of message-ids of the postings you've ever 'read'. How hard can *that* be!?
:-)
According to the official docs at https://www.sqlite.org/limits.html
this limit is 2 to the 64th power not twohundredandsixtyfour.
With that and a database table containing only 2 columns: MID and count
of read flags already set, the database would contain only one small row
per read message with only the numeric field changing after adding a
row. Replacing MIDs by fixed-size hashes of MIDs would allow fixed
length records, thus further easing the DB engine burden. Anyways disk
space for known messages would hit physical limits before the database
fills up.
The goal with this proposal is to handle 2 real world situations:
1. Cross-posts to multiple newsgroups from one server.
2. Having multiple newsserver accounts in one xxBird configuration, such
as news.dotsrc.org (the old SunSite) and eternal-september.org .
2. Having multiple newsserver accounts in one xxBird configuration, such
as news.dotsrc.org (the old SunSite) and eternal-september.org .
Frank Slootweg <this@ddress.is.invalid> writes:
Neither do I, but it's just SMOP (Small Matter Of Programming). All you have to do is to remember all the hundred of thousands / millions of message-ids of the postings you've ever 'read'. How hard can *that* be!? :-)
Well, we know exactly how hard this is, because you're describing a news server's history database. News servers also have to remember every
message they've seen, and they have to do that by message ID. News
servers limit this to articles within a certain date range and reject all articles older than that date range, but servers that never expire essentially keep that data forever.
There are a bunch of techniques for maintaining that database. It mostly uses dedicated data structures optimized for this specific problem, not a SQLite database, although I'd be interested to see someone try with modern SQLite or another SQL database and see if it can be optimized enough,
since those tools have a lot more general optimizations and way more
active developers.
This is certainly *doable*, since it's done all the time, and a modern
server is often smaller (in disk, memory, and CPU) than a typical laptop,
let alone desktop. On my news server, it currently takes up about 660MiB
of disk space, which is smaller than a lot of video games. :) But that's literally every message the server has on disk, and I can assure you that
I have not read the VAST majority of them, so most history databases for a personal newsreader would be substantially smaller.
It would have never occurred to me that somebody would expect this to
work across multiple servers ;-)
On 10/18/23 12:51, Jakob Bohm wrote:
2. Having multiple newsserver accounts in one xxBird configuration,
such as news.dotsrc.org (the old SunSite) and eternal-september.org .
XXbird? Does that mean there are more clients based on Thunderbird?
On 2023-10-19 10:11, candycanearter07 wrote:
XXbird? Does that mean there are more clients based on Thunderbird?
Yes, there's at least IceDove, BetterBird (first I heard of it),
Interlink (dead), Epyrus, Hermopolis, SeaMonkey (and other full Mozilla Communicator implementations).
I'm currently using Epyrus.
Jakob Bohm <jb-usenet@wisemo.com.invalid> wrote:
[...]
The goal with this proposal is to handle 2 real world situations:
As I've mentioned before, but you've ignored, your proposal handles
only *part* of the 'problems', only for relatively new not-seen
articles, not for - probably older - other not-yet-seen articles.
Having repeated that, let me comment on the "2 real world situations":
1. Cross-posts to multiple newsgroups from one server.
This is already handled by article-number ranges in .newsrc type
files.
That Thunderbird et al inherit a design-flaw from their predecessors
(as far back as Netscape Communicator or even further), does not change
this. Fix Thunderbird et al or live with the flaw.
2. Having multiple newsserver accounts in one xxBird configuration, such
as news.dotsrc.org (the old SunSite) and eternal-september.org .
That's only relevant if one's primary NSP is shaky and you need
another NSP in case as the primary one is down, misses articles, etc.,
etc.. (Best) Solution: Get a proper NSP.
But if you can't get a proper NSP, there's - as I mentioned several
times - Hamster (for Windows) and Leafnode2 (for Linux and Unix-like
OSs). That solves *both* the "2 real world situations".
Bottom line: 'Problems' solved. Next problem.
On 2023-10-18 20:35, Frank Slootweg wrote:
Jakob Bohm <jb-usenet@wisemo.com.invalid> wrote:
[...]
The goal with this proposal is to handle 2 real world situations:
As I've mentioned before, but you've ignored, your proposal handles
only *part* of the 'problems', only for relatively new not-seen
articles, not for - probably older - other not-yet-seen articles.
And you keep refusing to understand any proposals that deal with
imperfect (not necessarily broken) servers.
Having repeated that, let me comment on the "2 real world situations":
1. Cross-posts to multiple newsgroups from one server.
This is already handled by article-number ranges in .newsrc type
files.
This assumes the server has similar but more costly logic to identify cross-posted messages arriving at different times from different feeds.
That Thunderbird et al inherit a design-flaw from their predecessors
(as far back as Netscape Communicator or even further), does not change this. Fix Thunderbird et al or live with the flaw.
I am not referring to the "each newsgroup for itself" bug.
2. Having multiple newsserver accounts in one xxBird configuration, such >> as news.dotsrc.org (the old SunSite) and eternal-september.org .
That's only relevant if one's primary NSP is shaky and you need
another NSP in case as the primary one is down, misses articles, etc., etc.. (Best) Solution: Get a proper NSP.
Given the decline of usenet, the need to use more than one NSP is more
likely to grow than decline. My example specifically mentioned two
volunteer run NSPs with good reputation but different inclusion
policies.
Another example would be switching to a different NSP or a
different server at a single NSP while wanting to keep the "read" status
of messages already received from the previous NSP.
But if you can't get a proper NSP, there's - as I mentioned several times - Hamster (for Windows) and Leafnode2 (for Linux and Unix-like
OSs). That solves *both* the "2 real world situations".
That's an arrogant assumption, see above.
Bottom line: 'Problems' solved. Next problem.
https://www.dbtalks.com/tutorials/learn-sqlite/what-are-the-limitations-of-sqlite
A SQLite database can have maximum 2147483646 pages. Hence the maximum
number of tables in a schema cannot reach more than 2147483646. The
maximum number of rows in a table is 264. The maximum number of columns
is 32767 in a table.
Notice only 264 rows per table.
VanguardLH <V@nguard.LH> wrote:
https://www.dbtalks.com/tutorials/learn-sqlite/what-are-the-limitations-of-sqlite
I read this URL and immediately didn't understand why dbtalks.com is a reasonable place to look up information about or refer others to
SQLite's limitations.
A SQLite database can have maximum 2147483646 pages. Hence the maximum
number of tables in a schema cannot reach more than 2147483646. The
maximum number of rows in a table is 264. The maximum number of columns
is 32767 in a table.
Notice only 264 rows per table.
I noticed that you seem to have taken that seriously. Something should
have immediately caught your eye and made you think 'that is not
reasonable' particularly for a production-ready relational DB as
widely used as SQLite.
Okay, how about this from SQLite:
https://www.sqlite.org/limits.html
2000 columns (fields per record) maximum. Recommended: 100.
The default setting for SQLITE_MAX_COLUMN is 2000. You can change it
at compile time to values as large as 32767. On the other hand, many experienced database designers will argue that a well-normalized
database will never need more than 100 columns in a table.
VanguardLH <V@nguard.LH> wrote:
Notice only 264 rows per table.
I noticed that you seem to have taken that seriously. Something should
have immediately caught your eye and made you think 'that is not
reasonable' particularly for a production-ready relational DB as
widely used as SQLite.
Jakob Bohm <jb-usenet@wisemo.com.invalid> wrote:predecessors
On 2023-10-18 20:35, Frank Slootweg wrote:
Jakob Bohm <jb-usenet@wisemo.com.invalid> wrote:
[...]
Having repeated that, let me comment on the "2 real world situations": >>>This assumes the server has similar but more costly logic to identify
1. Cross-posts to multiple newsgroups from one server.
This is already handled by article-number ranges in .newsrc type
files.
cross-posted messages arriving at different times from different feeds.
Yes, *every* news server has that logic. It's called the history
database and it's not at all "costly", because it's a special database, specifically designed for this very purpose (see Russ' post). My
(Hamster) server also has it, because it couldn't be a news server
without it.
That Thunderbird et al inherit a design-flaw from their
(as far back as Netscape Communicator or even further), does not change
this. Fix Thunderbird et al or live with the flaw.
I am not referring to the "each newsgroup for itself" bug.
OK.
2. Having multiple newsserver accounts in one xxBird configuration, such >>>> as news.dotsrc.org (the old SunSite) and eternal-september.org .
That's only relevant if one's primary NSP is shaky and you need
another NSP in case as the primary one is down, misses articles, etc.,
etc.. (Best) Solution: Get a proper NSP.
Given the decline of usenet, the need to use more than one NSP is more
likely to grow than decline. My example specifically mentioned two
volunteer run NSPs with good reputation but different inclusion
policies.
What do you mean by "inclusion policies"? Retention policies or which groups they carry?
Anyway, a proper configuration (for Thunderbird et al) is not to get
the same groups from multiple servers. If you do want to do that anyway,
use Hamster/Leafnode(2).
Another example would be switching to a different NSP or a
different server at a single NSP while wanting to keep the "read" status
of messages already received from the previous NSP.
As said, Hamster/Leafnode(2) solve that problem.
But if you can't get a proper NSP, there's - as I mentioned several
times - Hamster (for Windows) and Leafnode2 (for Linux and Unix-like
OSs). That solves *both* the "2 real world situations".
That's an arrogant assumption, see above.
Why is that "an arrogant assumption"? Because it's a real life,
working solution to some somewhat farfetched problems, while your
proposal is a non-existing, partial solution, which is very unlikely to
be implemented?
On 2023-10-19 17:48, Frank Slootweg wrote:
Jakob Bohm <jb-usenet@wisemo.com.invalid> wrote:
On 2023-10-18 20:35, Frank Slootweg wrote:
But if you can't get a proper NSP, there's - as I mentioned several >>> times - Hamster (for Windows) and Leafnode2 (for Linux and Unix-like
OSs). That solves *both* the "2 real world situations".
That's an arrogant assumption, see above.
Why is that "an arrogant assumption"? Because it's a real life,
working solution to some somewhat farfetched problems, while your
proposal is a non-existing, partial solution, which is very unlikely to
be implemented?
And you assume that bad NSPs don't exist and don't have innocent users
who need their multipurpose client to handle the problem. Running
additional software before the need arises is a non-solution, unlike
putting fixes into software that gets installed as part of routine
software updates .
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 03:43:36 |
| Calls: | 10,387 |
| Calls today: | 2 |
| Files: | 14,061 |
| Messages: | 6,416,777 |