Subject: NNTP & [HOLES]

From: Mike Macgirvin <[email-masked]>
Date: Wed, 3 Nov 1993 12:04:53 -0800 (PST)

I'm working with the NNTP stuff in the c-client, and would like to 
request that the number of [HOLES] found be returned as an element (i.e. a new 
element) of the MAILSTREAM. Currently, this number is passed back to the 
application via an mm_notify() message, but as this happens in the process of 
doing a mail_open(), I don't yet have the return stream pointer in my list of 
control structures. So there's a catch-22, because until mail_open() returns, I
don't have knowledge of the MAILSTREAM which is passed to mm_notify(). 
Therefore I can't figure out which mailbox reported the holes and set their 
control structures accordingly.
	The chicken way out, supplying an allocated MAILSTREAM to mail_open(), 
isn't guaranteed according to my interpretation of the docs. "an attempt is 
made to reuse oldstream"; i.e. the attempt could fail, and I could still end up
with a new pointer that I have no knowledge of.
	The information is important, because the number of holes can be in the
tens of thousands, while the number of actual messages can be quite low, 
resulting in the possibility of massive over-allocation of resources.

mike

---

From: Mark Crispin <[email-masked]>
Date: Wed, 3 Nov 1993 15:58:54 -0800 (PST)

Mike -

     The [HOLES] condition should be nearly extinct in the most recent version
of c-client, if not totally extinct.  No known NNTP server will trigger it
today.  Make sure you have the version of c-client whose nntpclient.c module
tries the XHDR command if LISTGROUP fails.

-- Mark --

---

From: Mike Macgirvin <[email-masked]>
Date: Wed, 3 Nov 1993 21:36:25 -0800 (PST)

>  Mike -
>  
>       The [HOLES] condition should be nearly extinct in the
>  most recent version of c-client, if not totally extinct.  No
>  known NNTP server will trigger it today.  Make sure you have
>  the version of c-client whose nntpclient.c module

	..Didn't think I was -that- far out of date ;-) 
Thanks, the holes are gone. I was having nightmares trying to deal with them, 
so it's a good thing. 
	In the most recent nntpclient.c, though; none of the servers I know of 
recognize the "MODE READER" command which is used by the c-client  on an NNTP 
open; and the nntp_mopen() call fails if this command is unsuccessful.
	I imagine this just sets some modal stuff based on who's accessing the 
server, but it's just a guess, and things seem to work fine here without 
issuing it. I can't find mention of it in my NNTP docs. Is it dangerous to 
comment out this line? Pointers to a recent nntp server would be appreciated 
also. Latest I can find is 1.5.11 which is running; although I was able to find
the LISTGROUP patch via gopher. I've heard rumours of 1.6, but gopher can't 
find it, and archie has been down this evening. 

mike

---

From: Mark Crispin <[email-masked]>
Date: Thu, 4 Nov 1993 15:13:58 -0800 (PST)

Grumble!!  ;-)

This MODE READER stuff was added a short while back, because it appears that
in some NNTP server configurations it's mandatory to get the NNTP server in
the right state.

In the latest development sources, I've changed things so that it sends the
MODE READER command but completely ignores any response from it.  I hope to
have a new mail/imap.tar.Z in a few days; right now all my sources are very
broken.

Sorry for the problems.  I HATE protocols whose reality is not reflected by
the RFC's.  Well, this'll just push getting UID support into the IMAP toolkit
so the option will exist to punt on NNTP entirely...  ;-)

-- Mark --