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
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/pan-users
