Re: [Pan-users] Trivial change to header-pane.cc ?

[Duncan]

walt posted on Sat, 05 Jan 2013 01:20:34 +0000 as excerpted:

> If you take a look at (just for example) alt.binaries.photos.original
> you'll see quite a few posted jpegs with more than 5000 lines.
> 
> If you click on any of those articles (expecting to view the jpeg) pan
> will offer to save the attachment instead of displaying it.
> 
> The reason for this behavior is a test for article size in
> header-pane.cc (line 1277) to decide whether the attachment should be
> displayed or saved.  These days 5000 lines is evidently not big enough
> for many posted picture files, so I cheat and edit the file to change
> the 5000 to 10000.
> 
> The real problem is that the number is completely arbitrary, of course,
> and may increase in the future as digital cameras continue to improve.
> 
> I'm guessing that Charles found the problem annoying and settled for the
> existing code as 'good enough'.  Just a guess because I wasn't here back
> then.  But Duncan was :)  Any thoughts, Duncan?

I believe one of the big reasons originally was to prevent users on dialup 
accidentally clicking a huge multi-part post, triggering pan to download 
the whole thing, just to display it!  Popping up the save-as dialog was a 
hint to especially the dialup user that hey, this post is very possibly 
bigger than they might want to download on dialup, just out of curiosity 
or by accident.

At least back then, when many WERE on dialup, 5000 lines or so was about 
the biggest a single-part binary posting tended to be as well, and with 
even broadband tending to be sub-megabit (a 1.5 Mbit T-1 was SERIOUSLY 
HIGH SPEED, back then, and download speed or total periodic bandwidth 
caps were likewise rather smaller!), even broadband users would often 
have reason to pause at such an obviously multi-part post, as even a 5000-
line (especially yencoded) posting could take a minute or two to download 
and be using up non-trivial bandwidth quota in the process.

Of course one solution would be yet another configuration option, but I'm 
honestly not sure how many would find it useful, especially if that limit 
is raised to say 10-20 kline (50 kline? 100 kline?) by default.  
Personally, that's the sort of thing I'd tend to make a config-file-edit 
setting only, no GUI, as Charles did with say the cache size, which I 
/did/ actually think should be in the GUI.  At least editing the config 
file is a step easier than patching and rebuilding the sources.  But if 
enough people feel strongly enough about different defaults, then maybe a 
GUI config option too.

Another alternative would be to link that setting to the multi-choice 
option I proposed for cache-size earlier, such that a user could choose 
their common usage and have settings such as this and cache size tuned 
accordingly, between text (10M cache, 1000 line save-as break), still-
image (200M cache, 20 kline), mp3 (500M cache, still 20 kline from here 
up as pan doesn't display them anyway), cd-iso (1-2G cache) dvd-iso 
(5-10G cache), bluray-iso or multiple ISOs (50G cache), an I'll set my 
own settings option, with text-boxes for both settings, and whatever 
other settings might be appropriate as well.

But yes, I'd suggest at least raising the default to 10-20 kline and 
making it a config file setting, with or without a GUI setting to match.

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