[Twisted-Python] Some comments on twisted.news

[Jp Calderone]

On Tue, Oct 22, 2002 at 06:49:09PM +0100, Paul Moore wrote:
> 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
>    working.

  Glad to hear it :)

> 
> 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).
> 

  Oops, thanks for the report.

> 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.

  I agree that \n would probably be preferable, this was just sloppyness on
my part in the initial implementation.  I think it could be changed in such
a way so as not to break existing code, but allow new code to use \n
(similar to how LineReceiver works), and I think this would be a good thing
to do.

> 
> 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).

  Hmmm.  I have an {indeterminant}-term goal of creating a better backend
interface.  If this isn't a pressing concern for you now, I'd rather put it
off until that happened (though I'd have no problem if you sent a patch that
made the necessary changes).

> 
> (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?

  I've been away a while, so maybe you've already gone ahead and done some
of this?  If not, I might have a crack at it myself.  I'll wait to hear
what, if anything, you've done thus far though.

  Jp

-- 
If the automobile had followed the same development as the computer, a 
Rolls-Royce would today cost $100, get a million miles per per gallon,
and explode once a year killing everyone inside.
                -- Robert Cringely, InfoWorld
--
 12:00am up 164 days, 1:59, 5 users, load average: 0.12, 0.13, 0.10
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20021101/4a60eeea/attachment.pgp