On Thu, 02 Jul 2009 23:53:53 +0000, Duncan wrote: > Ron Johnson <ron.l.john...@cox.net> posted > 4a4cf8fc.8030...@cox.net, excerpted below, on Thu, > 02 Jul 2009 13:14:20 -0500: > >> Because giganews has such a long retention period, some groups can have >> a very *large number* of messages. If you subscribe to two or more of >> them, you could run out of memory. >> >> As it is, pan seems to sequentially scan thru all messages when marking >> a group of them as Read. >> >> There needs to be a better and less memory intensive method of handling >> huge groups. B-trees, hash tables, SQL-Lite, I don't know, but >> *something* better than the status quo.
The basic problem overwhelming usenet is that people are using it for file sharing, a purpose for which it was not intended and is not well suited. But you knew that already :o) It would be an interesting novelty for news servers to offer a well-compressed zipfile of article headers, say, for each calendar month or week. > ...at least one group on Giganews has "rolled > over" the 32-bit article sequence integer pan uses. It needs to be a > 64- bit number, or at least 33-bit. More groups will follow over time. > AFAIK there's a patch floating around to allow pan to deal with this... Our recent pan angel, K. Haley, has already included that change in his/her git archive (git://github.com/lostcoder/pan2.git) for which I once again send my thanks to him/her. _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
