For cross-posts, is there any way to automatically mark the message read
in the other groups its posted to once I read it?
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
Yes AFAIK. Which newsware are you using?
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.
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.
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.
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.
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.
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.
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 ;-)
Ray Banana wrote:
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 ;-)
Why would you? The point of USENET is shared posts across all servers,
right?
Since Thunderbird switch to SQLite long ago, and record structures
would be modified to add a field for MID, doesn't seem that much an
onus to code for the same MID across the SQLite databases for all
folders. However, that probably would incur a delay between when
the Read button was pressed until the message changed formatting
(bold to unbolded).
By using MID, seem plausible the read-state could be reflected for
the same message across newsgroups polled from different servers.
Not an elegant solution, but a possible one. Yet interest seems to
have faded with the Tbird dev folks.
VanguardLH <V@nguard.LH> wrote:
Since Thunderbird switch to SQLite long ago, and record structures
would be modified to add a field for MID, doesn't seem that much an
onus to code for the same MID across the SQLite databases for all
folders. However, that probably would incur a delay between when
the Read button was pressed until the message changed formatting
(bold to unbolded).
Why not do that job in a background task/thread?
By using MID, seem plausible the read-state could be reflected for
the same message across newsgroups polled from different servers.
Not an elegant solution, but a possible one. Yet interest seems to
have faded with the Tbird dev folks.
Why would that be inelegant? It seems to me that using the only
approach one could use to implement a nice feature ought to qualify as elegant.
I'd appreciate marking the same articles as read (and
updating all dependencies including unread article counts, newsrcs,
and saved searches) across one's news servers so I don't have to waste
time re-marking stuff read multiple times.
As I mentioned in another response, Hamster can aggregrate articles
from several news servers and solves this problem. I see that you're
using slrn on Linux, so you can not (easily) use Hamster (which is a
Windows program). But you might want to look if Leafnode can do the same
on Linux.
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 ;-)
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 102:09:03 |
| Calls: | 6,700 |
| Files: | 12,232 |
| Messages: | 5,350,044 |