Duncan <1i5t5.dun...@cox.net> [Wed, 08 Jun 2011 10:22:50 +0000] [...] > And it'd be an even BIGGER bonus if someone came up with a patch that > allowed pan to work with primarily compressed headers and only > decompress, say, the page it's displaying and the page before and after > that, thus killing two birds with one stone, if pan then used LESS > memory than before, as WELL as allowed on-disk compression
Yes, that was the idea, keep those big files in $HOME/.pan2/groups/ in a compressed state, as they are large ASCII lists. In fact, the files $HOME/.pan2/news* could be compressed as well. Unfortunately I am not able to program patches, but using compressed files might be a simple enhancement as long as pan just decompresses the file upon accessing it (i.e. when opening a group). I am not talking about the files in the cache though, files in a cache should be plain and fast. BTW, even better than compressing those files would be encrypting them, for example through gpg. This would be a big enhancement in privacy. Keeping the file compressed in memory sounds much more complex from a programming point of view. > (presumably > controlled with an option, altho it might be a file-only option without > a UI switch, a number of pan features work that way in ordered to keep > the complexity of the options dialogs down). I agree, a UI switch is not needed. _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
