Re: [Pan-users] Pan/0.142 Header shown twice?

[Duncan]

Dave posted on Sun, 08 Oct 2017 23:46:08 +0000 as excerpted:

> On Sun, 08 Oct 2017 18:05:38 +0200, Detlef Graef wrote:
> 
>> Am 08.10.2017 um 17:17 schrieb Dave:
>>> On Sun, 08 Oct 2017 14:49:39 +0200, Detlef Graef wrote:
>>> 
>>>> can someone confirm that in Pan/0.142 the header of an article is
>>>> shown twice? When I read an article and press the key "h", the header
>>>> is shown twice. In 0.141 I didn't notice this behaviour.
>>>>
>>> Yes, you are correct.  It's rare I do that so hadn't noticed.
>> 
>> Thanks for checking this.
>> 
>> I've looked at the source. In the file body-pane.cc line 1242 there is
>> the following call:
>> 
>> char * headers (g_mime_object_get_headers ((GMimeObject *) message));
>> 
>> The function g_mime_object_get_headers() returns the header twice, I've
>> checked this. ("headers" contains the article headers twice)
>> 
>> g_mime_object_get_headers() is part of the GMime lib. I'm using Fedora,
>> Pan 0.141 is bundled with Fedora 25, Pan 0.142 is bundled with Fedora
>> 26.
>> 
>> Fedora 26 is bundled with GMime 2.6.23 (gmime-2.6.23-2.fc26.x86_64).
>> Fedora 25 is bundled with GMime 2.6.20 (gmime-2.6.20-7.fc25.x86_64).
>> 
>> Can you please check which version of GMime is installed on your
>> system?
>> 
>> Today I've tried to reply to a posting, and I got the following error:
>> 
>> 441 Invalid syntax encountered in References: header field body
>> (unexpected byte or empty content line)
>> 
>> the posting failed. Maybe this is somehow related.
>> 
>> 
>> Detlef
> 
> Oh dear, not gmime again!
> 
> FreeBSD 10.3-RELEASE-p20 pan-0.141 gmime26-2.6.23
> 
> Last time Pan was having issues with headers, it was screwing up the
> references headers and splitting in a non-standard place causing
> threading to break after more than a 2-3 deep reply.  I was building
> against gmime24 for a long while 'till that got fixed. ie, it was gmime
> NOT pan at fault.

Indeed, gmime bugs have tripped up pan and pan users a number of times.

FWIW, I'm on gmime-2.6.23 here on gentoo as well, and see the double-
headers too, tho I too hadn't noticed it before reading this thread.

> I doubt I can help much with this though.  I've not written code in
> many, many years.  About the most complicated thing I do these days
> apart from a bit of bash scripting is edit the Pan source code to
> increase the number of threads to 30 per server whenever a FreeBSD port
> comes along.

As you may know but it's worth repeating for others that may be reading 
in any case, editing source code isn't absolutely essential for that 
tweak.  There's actually quite some history behind that setting, and it 
works exactly the way it does (as I'll explain) for a reason (which I'll 
also explain).

The original reason for the 4-connections-per-server GUI maximum is 
GNKSA.  Of course in a chaotic internet reality of server abuse the 
server must control this setting server-side in any case, and 
particularly dedicated NSPs tend to deliberately allow far more than 
four connections, especially for block or overall-byte-capped (as opposed 
to per-connection byte-capped) accounts, because more connections 
encourages you to use more, and thus be more likely to pay for a higher 
tier of service if byte-capped, or have to renew sooner if block-
account.  So most folks with any knowledge of the subject agree that this 
particular GNKSA requirement is dated, /even/ /when/ /they/ /tend/ /to/ 
/agree/ /with/ /GNKSA/ /in/ /general/.

But there has long been a workaround, described below, that doesn't 
require code patching, while maintaining GNKSA compliance due to a 
(possibly deliberate?) loophole in the wording of that particular 
requirement.

Now back when Heinrich was very active as a pan developer, he actually 
patched the 4-connection limit out, provoking perhaps one of the most 
important discussions about pan's future I've ever seen on this list, 
with me being the OP, posting the question for users to consider.

While the immediate question was whether people thought that connection 
uncap commit should be reverted to maintain 100% GNKSA compliance, or 
left at the much higher or effectively uncapped (IDR which, but I do 
recall that the 50-connections I've seen some NSPs allow was possible), 
naturally, that lead to a debate on whether pan should continue to worry 
about GNKSA at all, if we were no longer going to be 100% complaint.  
Putting aside that individual requirement, was/is GNKSA itself entirely 
outdated and no longer worth worrying about, or not?

Naturally there's some rather strong feelings on the subject among pan 
users, especially because pan tends to draw a certain kind of user, which 
may be described by many as "old fogies", in part /because/ of its 
history of GNKSA compliance.

>From that thread, the general consensus seemed to be that GNKSA /was/ 
worth keeping in general, and that particularly /because/ the workaround 
to the GNKSA connections requirement was available for those who cared 
enough to bother, and additionally because the feeling (which I shared 
but thought it only fair that the community decide) seemed to be that 
once we let that 100% slide, we might find ourselves on a slippery slope 
that would ultimately lead to pan losing other GNKSA requirement 
compliance, it simply wasn't worth losing that 100% GNKSA compliance just 
to let people use the GUI to set more connections.

Evidently Heinrich agreed with the community conclusion too, as he 
reverted that commit.

Which is why we still have the 4-connections limit in the GUI today.


So that's the history, but what's the workaround?  As may now be apparent 
to those following along, the GNKSA requirement is that a complaint news 
client limit the max connections to four per server in its 
configuration.  That would be the GUI configuration for GUI-based clients 
such as pan.  What it does *NOT* say is that a client is required to 
*ENFORCE* such a maximum if the user configures a higher maximum 
manually, say by editing the config file itself, setting a higher number 
of connections there than the application will allow when set via the 
application itself.

Thus the non-code workaround is to edit the config file, in this case 
servers.xml in the pan config dir (~/.pan2 by default, but it can be 
pointed elsewhere via the PANHOME environmental var, a feature I use via 
wrapper scripts to allow multiple pan instances, each with their own 
settings, here), to allow the desired number of connections.  Any 
(reasonable) number of connections you set there should be honored. 
(65535 arguably isn't reasonable, but without checking the size of the 
integer storing the value, I believe it's a safe bet to say it's at least 
an 8-bit char, so 255 connections should be possible... if your NSP 
allows it, of course.  I think some  allow 100.  I'm not aware of any 
allowing more than that.)


Of course if you reconfigure the server settings in the GUI again, and 
save your changes, it'll overwrite back to 4 connections max again, but 
that's easily remedied by either avoiding the GUI for server config 
changes, or using the GUI and then resetting the connections value 
manually.  It's not as if you have to change your server config every pan 
session, after all. =:^)


So patching the code and building pan yourself isn't required to set more 
than four connections per server, thus allowing those sufficiently 
motivated and tech literate enough to edit a text-based config file to 
set what they like even if they aren't tech literate enough to apply 
patches and build pan from sources (or if they are but they simply don't 
want to bother).

But for those who already build pan from sources anyway, such a patch to 
allow setting more than four connections in the GUI may be easier than 
manually editing servers.xml and remembering not to mess with the 
settings in the GUI, or to reset the number of connections manually if 
they do.

With both the manual edit method and the patch to allow gui edit method 
available, as I said, the list consensus seemed to be to keep the pan 
sources as shipped 100% GNKSA compliant, tho I have a feeling the 
consensus may have swung the other way without the manual edit method.

Regardless, I'm glad the manual edit method is there, *AND* I'm glad the 
consensus was to keep PAN 100% GNKSA compliant, quirky tho that might be 
in today's environment.  Because pan really does tend to attract users 
that appreciate those "features", quirky tho they might well be to much 
of the rest of the world, and I must say I'm quite happy to be counted 
among that "quirky old fogey" bunch. =:^)

Meanwhile, I've one more point to make on the server connections topic, 
but I'll make it in a followup post, as it could potentially lead to its 
own subthread...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman