I just set up a basic demo new server using twisted. Some initial comments:
1. It took me almost no time to put together a basic dummy NNTP
server. Just create the backend, put a mktap driver in, and it's
2. There seems to be a problem with the server class. It translates
\r\n.. to \r\n. in the data the backend supplies - this should be
the other way round (it should be *doubling* the dots, so that they
don't look like the end of data marker to the client).
3. It would be nice if the server handled the translation to CRLF, so
that backends could return data with lines separated by \n, and the
server class would convert that to \r\n. After all, \n is the
"normal" end of line character internal to Python code, and \r\n is
a feature of the NNTP protocol, so the protocol driver should be
responsible for the conversion (IMHO). Of course, this is a
behaviour change, which could break existing backends, so maybe
it's not practical to make this change.
4. The implementation of STAT requests the article from the
backend. This could be inefficient if getting the message ID is
cheap, but getting the full article is expensive for a particular
backend (it will be for me). In my partly-implemented NNTP server
written in "raw" Python (before I found Twisted) I had a backend
method getArticle(..., head=1, body=1) which was used to implement
all of HEAD, BODY, ARTICLE and STAT, just by setting different
values for the head and body parameters (so the backend could check
for the case where neither was required, and act accordingly).
(2) is obviously fairly trivial. I think I could implement (3) and
(4), if it would be useful. I could submit a patch, which would alter
the server code and the 2 existing backends (I couldn't test the
database backend, as I don't have a database to test with, but I could
test the pickle-based code). Would this be helpful? Are there likely
to be 3rd party nntp backends which would be broken by such a change?
This signature intentionally left blank