On more fundamental open source grounds, requests like these are generally just useless noise. Development happens when someone wants some software to do x,y,z task, cannot find anything to their liking, and so the person then goes and writes the software themselves. If they share it with others, that's when you get open source!
I've always wanted to have a simple local news server that was also easily connected to a web forum. The lack of any sort of standardization among forums, or worse, the ones that try to use DAV and XML to "share" drives me nuts. So I've never had my small little news site. That's the itch that I might scratch by writing an NNTP server. Leif's advice is well taken, though. Usenet is a scary place to be; I've seen the news servers at my local ISP keep the access lights on a RAID array solidly lit all day and all night. And it's a small ISP. Aaron ""Leif Jackson"" <[EMAIL PROTECTED]> said: > Ed, For good reason, > > I used to work for one of the worlds largest NNTP providers. And believe > me from experience we do not want to get into NNTP stuff. The reason none > of the currently available NNTP server code uses an RDBM is that the file > IO is so heavy and requires so much IO that it takes all of a fiber > channel disk system and Sun 420R's with 4G of ram to keep up with a full > NNTP feed. Much less serve any end users. Roughly about 65Mbps (to > 90Mbps) for a full feed now, scary eh? > > my suggestion is to leave nntp alone :) > > -leif > > > Let me know when the NNTP service starts development. > > No other NNTP servers that I've found use a RDBMS backend. > > > > ed > > > > On Mon, 15 Mar 2004, Aaron Stone wrote: > > > >> This is really, really good... I wonder if it can be combined with a > >> macro or > >> built into a macro so that the "if (ci_write) return -1" could be > >> "ci_write" > >> and since there's only ever one stream to write, "ci->tx" could be > >> assumed. > >> > >> The LMTP code doesn't use the ClientInfo structure, but in the process > >> of > >> refactoring the server code these sorts of micro-differences should be > >> brought > >> together so that the ClientInfo structure is either generic enough or > >> beefy > >> enough (just toss all of the different elements into it) to handle IMAP, > >> POP, > >> LMTP, and whatever else comes next (NNTP anyone? ;-) > >> > >> Aaron > >> > >> > >> Paul J Stevens <[EMAIL PROTECTED]> said: > >> > >> > > >> > Hi all, > >> > > >> > Since there were no takers, I did a follow-up on my earlier conclusion > >> > that the networking code could do with some improvements. > >> > > >> > For those of you who haven't followed the list; dbmail2 won't work > >> with > >> > mozilla and derivatives. > >> > > >> > I've wrapped the code talking to clients in simple wrappers with error > >> > checking, and lo; mozilla suddenly works just fine with dbmail2 :-) > >> > > >> > As a proof-of-concept I'm attaching my patch against the HEAD branch > >> as > >> > of today. > >> > > >> > This is not for inclusion in CVS just yet. It's still kind of rough, > >> but > >> > I wanted to share my relief that this really does appear to fix the > >> bug. > >> > Also, pop3.c and lmtpd.c would probably also benefit from this > >> approach > >> > as well. > >> > > >> > IMO imap4.c and friends could do with some re-indenting. Looks like > >> > there are several different indent-styles intertwined in the code. Any > >> > consensus on that regard ? > >> > > >> > > >> > -- > >> > ________________________________________________________________ > >> > Paul Stevens mailto:[EMAIL PROTECTED] > >> > NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED] > >> > The Netherlands________________________________http://www.nfg.nl > >> > > >> > > >> > >> > >> > >> -- > >> > >> > >> > >> _______________________________________________ > >> Dbmail-dev mailing list > >> [email protected] > >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >> > > > > Security on the internet is impossible without strong, open, > > and unhindered encryption. > > > > _______________________________________________ > > Dbmail-dev mailing list > > [email protected] > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
