Hi,
I working for gsoc creating NNTP access to the mailing list archives for Mailman 3. Therefor I tried Twisted NNTP, during the last days. I noticed, that it is not standard conform in any way. For example: it missing required commands and returns wrong error codes on unknown sub commands.
I will try to fix it. But while I modify it, I could port it to asyncore/async_chat. Would it be preferred? anyncore is bundled with core python and so the new implementation would be runnable without depending on Twisted. But if patching the Twisted implementation, other projects using it could gain profit, too.
So what is your position?
Thanks, Alex
On Jul 03, 2012, at 02:55 PM, Alexander Sulfrian wrote:
I working for gsoc creating NNTP access to the mailing list archives for Mailman 3. Therefor I tried Twisted NNTP, during the last days. I noticed, that it is not standard conform in any way. For example: it missing required commands and returns wrong error codes on unknown sub commands.
I will try to fix it. But while I modify it, I could port it to asyncore/async_chat. Would it be preferred? anyncore is bundled with core python and so the new implementation would be runnable without depending on Twisted. But if patching the Twisted implementation, other projects using it could gain profit, too.
I guess one question is whether it's more work to fix Twisted's NNTP protocol support or bootstrap the whole thing from scratch async. I don't know how involved NNTP is, so a careful reading of RFC 6048 would be in order first. Last time I tried it (admittedly many years ago), Twisted was good enough for a couple of NNTP clients I tried.
Does the NNTP server part of it have to be fully conformant for you to show progress on the Mailman integration work? IOW, maybe it's good enough that you don't need to be side-tracked right now on fixing Twisted's support. Maybe if nntplib, Thunderbird (and selfishly, Claws) can read the archives via NNTP, that would be enough for now. If you go that route, definitely file bugs with Twisted for any protocol defects you find.
In a similar way, if you think implementing RFC 6048 on top of async will not distract you too much, then don't worry about getting that perfect. Get it good enough for a few clients to do the common things, and then work on the Mailman integration parts. If you're still interested, you can come back to the NNTP bits and refine them. (An nntpd.py would be an interesting subproject, and probably mostly standalone from Mailman.)
How much can you get done without committing to either Twisted or a new async-based NNTP server? Maybe there would be a lot of commonality between the two backends, so that you could work on the code in such a way that it wouldn't be difficult to switch between them.
Hope that helps, -Barry
On 7/3/2012 4:30 PM, Barry Warsaw wrote:
I guess one question is whether it's more work to fix Twisted's NNTP protocol support or bootstrap the whole thing from scratch async. I don't know how involved NNTP is, so a careful reading of RFC 6048 would be in order first. Last time I tried it (admittedly many years ago), Twisted was good enough for a couple of NNTP clients I tried. You mean RFC 3977--RFC 6048 only extends the LIST command.
In practice, you'd need to implement ARTICLE, HEAD, BODY, STAT, LIST, NEXT, LAST, and QUIT to be compatible with all clients (the necessary parts for readers for RFC 977). (X)OVER and the other LIST commands would be extremely nice, as would, to a lesser degree, (X)HDR, XPAT, and CAPABILITIES. Essentially, only those commands that need the READER and LIST capabilities under RFC 3977 (and their 2980 counterparts). AUTHINFO would be a good idea if you want to support password-protected archives.
-- Joshua Cranmer News submodule owner DXR coauthor
At Tue, 03 Jul 2012 16:48:43 -0400, Joshua Cranmer wrote:
On 7/3/2012 4:30 PM, Barry Warsaw wrote:
I guess one question is whether it's more work to fix Twisted's NNTP protocol support or bootstrap the whole thing from scratch async. I don't know how involved NNTP is, so a careful reading of RFC 6048 would be in order first. Last time I tried it (admittedly many years ago), Twisted was good enough for a couple of NNTP clients I tried. You mean RFC 3977--RFC 6048 only extends the LIST command.
In practice, you'd need to implement ARTICLE, HEAD, BODY, STAT, LIST, NEXT, LAST, and QUIT to be compatible with all clients (the necessary parts for readers for RFC 977). (X)OVER and the other LIST commands would be extremely nice, as would, to a lesser degree, (X)HDR, XPAT, and CAPABILITIES. Essentially, only those commands that need the READER and LIST capabilities under RFC 3977 (and their 2980 counterparts). AUTHINFO would be a good idea if you want to support password-protected archives.
RFC 3977 explicit requires the CAPABILITIES command to work for conformance. It should not be hard to implement it, so in my opinion it should be listed as required.
@TOPIC: I will try to create a async_chat wrapper for the NNTP protocol. I think that this should not be very hard. The only difficulty would be the parsing of the command with multiple lines as argument.
Alex
Alexander Sulfrian writes:
RFC 3977 explicit requires the CAPABILITIES command to work for conformance. It should not be hard to implement it, so in my opinion it should be listed as required.
Sure, but please remember that *you* have a deadline. When you write up requirements, make sure you distinguish between "what Mailman should have to be a good citizen" and "what Alex promises for GSoC".
I *guess* that what others are talking about is the latter. IMO Barry's pragmatic test (a quickie driver around nntplib and TBird should be able to read articles) is what you should be aiming at first.
Steve
participants (4)
-
Alexander Sulfrian -
Barry Warsaw -
Joshua Cranmer -
Stephen J. Turnbull