[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-devel] where in the code would I address server I/O errors and

From: Heinrich Müller
Subject: Re: [Pan-devel] where in the code would I address server I/O errors and retries
Date: Thu, 14 Nov 2013 17:26:40 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

Am 14.11.2013 13:54, schrieb Rob:
I'm a QT programmer so I'm not too well acquainted with the gtk callback 
structure.  I need to find the server I/O functions in the code to address a 
problem with a non-RFC compliant usenet service.

It seems that a trend these days with the large usenet providers is to NOT hold all 
content locally on their servers, but to onlyinitially receive headers and to only cache 
articles locally when they are requested by a client.  This process breaks nntp fairly 
easily if there is any substantial delay between the client requesting an article and the 
provider going out and finding it.  I'm not convinced that pan is handling this as well 
as can be.  Another concern I have is that when pan issues a GROUP command that the 
"last" article number is invalid...meaning that way too often the server 
responds with a 501 error code when chunks of article headers in the value group range 
are retrieved.

In simplest terms I'd like to make sure that pan is retying some number of 
times when a 501 error response is generated with downloading new article 
headers.  My understanding is that header downloading would use the XHDR 
command and download in chunks...well, sometimes the requested chunk generates 
the non-conformant 501 error.  I want to check for this and retry when it 
take a look at and
nntp does the error handling and task-xover receives the headers and updates the internal data with new headers and stuff
on a deeper level, there are the socket-impl* classes.
On a related note, the regular expression capabilities don't seem to be 
documented at all and I have yet to figure out what dialect of regular 
expressions are supported when searching the Subject: field...or if the RE 
functions are well supported and tested in the application.

I thinks it's a perl regex derivate.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]