On 2023-10-19 10:11, candycanearter07 wrote:
> 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?

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.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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.
>

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

On 10/19/23 09:12, Jakob Bohm wrote:
> 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.

Thanks, might check those out.
--
user <candycane> is generated from /dev/urandom

Jakob Bohm <jb-usenet@wisemo.com.invalid> wrote:
> 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.

No, I don't refuse anything and I fully understand what you're saying.
However what you seem to be unable (unwilling?) to accept, is that some
(even many) people in these groups, especially in news.software.nntp,
have a long and a lot experience in these matters.

> > 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.

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 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.

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?

> > Bottom line: 'Problems' solved. Next problem.

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.

"J.B. Nicholson" <jbn@forestfield.org> wrote:

> 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.

There are possible maximums, and there are feasible maximums based on
performance. SQLite is not good for huge or even large databases, and
even SQLite says that.

VanguardLH <V@nguard.LH> wrote:
> Okay, how about this from SQLite:
>
> https://www.sqlite.org/limits.html
>
> 2000 columns (fields per record) maximum. Recommended: 100.

I don't understand why you're discussing SQLite's column limits per
table when I pointed out that you quoted a clearly disreputable source
about SQLite's row limits per table. And I think that you're
misstating what https://www.sqlite.org/limits.html says.

Here's a quote from https://www.sqlite.org/limits.html:
> 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.

The SQLite.org text is correct in its statement about 100 columns in a
table but SQLite clearly supports more than an order of magnitude more
columns per table in its default compiled-in limit. But the
interesting things in the context of this thread are row limits per
table, the veracity of the source you picked, and that if one wants to
know about SQLite one goes to sqlite.org.

On Tue, 24 Oct 2023 05:17:05 -0000 (UTC), J.B. Nicholson <jbn@forestfield.org> wrote:
> 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.

It seems like simple formatting error though, i.e. not supporting superscript correctly.

So, it is not "264" rows per table, but 2^64 (two to the power of 64, or 18446744073709551616) rows per table.

Which is evident in other parts of the page too where it says e.g.
"The current implementation will only support a string or BLOB length up to 231-1 or 2147483647"

231-1 is 230, and obviously nowhere near 2147483647. 2^31-1 however is exactly 2147483647.

--
Opinions above are GNU-copylefted.

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:
>>> Jakob Bohm <jb-usenet@wisemo.com.invalid> wrote:
>>> [...]

>>> 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.
>
> 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
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.
>
> 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?

I mean all of groups carried, retention and messages filtered .

>
> 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).
>

I am talking about getting group A from server A and group B from server
B, then someone crossposts to groups A and B via a server C that carries
both group A and group B. This means that neither server A nor server B
will have server side ability to report the crosspost via per-server IDs
to a client that gets A from A and B from B.

>> 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 we are discussing a client which is neither named Hamster nor
Leafnode.

In my case, I was caught unprepared when Giganews suddenly turned off
their Europe server, forcing me to switch to their global server and
loose all message states in the existing XxxBird client. This may have
been caused by the "each newsgroup for itself" but in the user interface
it was casued by having to resubscribe to the groups when the server
name changed.

>
>>> 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 .

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Jakob Bohm <jb-usenet@wisemo.com.invalid> wrote:
> 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:

[Most endless repetitions deleted.]

> >>> 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 .

Again, please don't put words in my mouth! Of course I know full well
that "bad NSPs" exist, that's why I said what I said and gave
alternative solution which *actually exist* and *actually work* (and use
a "proper NSP" myself).

You OTOH, continue to talk about paper tigers. As I said, your
proposal is very unlikely to be implemented (in Thunderbird). If you
think otherwise, prove me/us wrong by putting your proposal to the
people who can actually implement it, i.e. Mozilla, instead of
footstamping in these groups, where it won't change anything.

Let's agree to disagree.

(AFAIC,) EOD.