Thunderbird and MIDs (was: Re: why graphical screenshot? from a command prompt console window?)

On 2026/2/19 15:2:47, Paul wrote:
[]

> Did you test with a Nightly, as a check for forward-progress ?
> I'm not familiar at all with running these, but this is the
> quickest way to tell whether the MID mod got any traction.

No, I'm on the ESR line - quite the opposite of nightlies!

> You would be doing this for science <snicker>. A thing like this
> should start with a private profile. The profile might even be
> inside the launch folder, rather than being in AppData. When
> I tested with the Betterbird Portable, that should be largely
> similar to the operation of the Nightly. I would be testing
> this in a VM, because I hate cleaning up a mess, and I just
> shovel these VMs into the trash :-) The one I was using for
> the Betterbird test, is already gone. When you do a build yourself
> of Thunderbird, these days, with an HG (Mercurial pull), one of the
> outputs would be one of these.

I haven't "built" anything for I think over 40 years! I don't think I
even have a compiler these days, unless there's one present as part of
Windows or similar.
> 
>    https://ftp.mozilla.org/pub/thunderbird/nightly/2026/02/2026-02-19-10-01-27-comm-central-l10n/
>    https://ftp.mozilla.org/pub/thunderbird/nightly/2026/02/2026-02-19-10-01-27-comm-central/
> 
> The method I observed being used in Betterbird is "technical"
> but not "optimal", and it depends on how snooty the TB devs are
> as to whether the idea would have any traction at all. The launch from
> command line, as a URI, that's the slow one, the while-running selection
> of Mork Summary Files to scan, seems to be faster.
> 
> There might be a small amount of similarity, if someone were implementing
> a crosspost-read feature. You could clumsily do it by keeping a lot
> of group.msf files open, with a resulting larger-average RAM footprint.

Yes, I see what you mean.

> The current devs will always be thinking in terms of scalability,
> which many people here (with one exception) would not be testing
> and commenting on. My subscription list is too short to notice
> how slug-slow it would be with a thousand groups subscribed (but
> not actively read). There's even a danger for people on smaller
> machines, they might run out of RAM if they subscribed to a thousand
> groups and a MID-launch was attempted.

Wow, I can't imagine having such a subscription list! (Can't think _why_
I would, if I wasn't going to read them.)

> 
> There seemed to be some difference, in how Netscape Communicator treated
> multiple USENET servers, and perhaps how Thunderbird treated them. This
> led to the <cough> bug we used to see, where it would triumphantly claim
> "you cannot send to two servers at once", and how it used to cherry

Now you mention it, I vaguely remember some such message when I was
using Turnpike (which _did_ handle crossposted posts properly - reading
them, or marking them as "keep", in one 'group made them so in the
others, whichever one you did them in first. I don't know if it stored
multiple copies).

> pick group a.b.c from AIOE and d.e.f from E-S. There is something you
> can type, into the newsgroup area to stop that (basically directing
> the stupid thing to stop auto-selecting servers, then denying such
> a function exists), but that was an issue for quite a while.
> 
> The USENET news component was re-written in javascript, and that was
> the opportunity to change the internal architecture away from the
> fractured thing it used to use.

Was the opportunity taken? (I've only stared using TB in the last year -
I think it might have been version 138; I did dabble with it decades ago
[single-digit I think], but used Turnpike until I had to go 64-bit.)
> 
>    Paul
> 
John

-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf