Greg Lee <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 01 Sep 2007 17:12:52 +0000:
> Since getting headers can be very time-consuming, very _very_ > time-consuming, I think what's needed is an estimate of the number of > headers available, which does not involve actually fetching the headers. > From the behavior of the newsreader I used previously, I'm guessing > that information is available from the news server. I realize the > disparity between the count of articles and the count of article parts > would a problem ... I had forgotten about the get header count option... but yes getting overviews would seem the only other option. Another alternative, perhaps easier on slow connections, would be to get X amount of headers, and see how far back that takes you. 300 (the default IIRC) may be too few to be significant, tho it'd at least tell you if the group was totally vacant, but say 1000. If you get a thousand headers from a group and it goes back an hour, you know it's a pretty active group. If you say get a thousand, but it only fetches 3, and the earliest one is a year and a half ago, well... Finally, it doesn't much help from pan, but you can always telnet into the server, and get a count manually. As you said, it's a simple command issued to the news server -- altho the return result isn't necessarily accurate. (The RFCs say it cannot be less than the actual number, but it can and sometimes is more than the actual number, and how far off it is... that's a server, group, and often time dependent variable.) IIRC it's the "group" command. It returns several numbers, including a status code, and the first and last article number (as in the xref header), followed by the server estimate of the number of posts available Article numbers are sequential, so the estimate shouldn't be more than last minus first, but if messages have been canceled, or came in out of sequence (maybe they are numbered on an incoming server then sent to the customer server, and got stuck in between), or if a spam filter removes some after numbering, then there may be fewer messages than last minus first or the estimate indicates. As I mentioned, the estimate is allowed to be high, but not low, according to the spec. This allows the client to use the estimate for preallocating a memory buffer if desired, if it knows it needs X bytes per article overview. Of course, a buffer overrun isn't a good thing, thus the spec saying it can be more than the number of actual messages, but not less. Again, that's "IIRC", and "IMNRC", but the idea is right, even if the details may not be exactly so. It doesn't hurt to read up on things tho, and trying a telnet session can be quite enlightening, if you've never done so before. It gives you a MUCH better appreciation of what a news client actually does for you behind the scenes. =8^) -- 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 http://lists.nongnu.org/mailman/listinfo/pan-users
