Has anyone created a simple POP3 and SMTP server using TWISTED?

[Donn Cave]

Quoth Jp Calderone <exarkun at intarweb.us>:
[... entering miserable thread that has gone on far past its useful lifespan]
|>|> | If this is so, how does inetd work?
|>|> 
|>|> Doesn't.
|>|> 
|>|
|>|   You're kidding, right?
|> 
|> Not at all.  Why?
|
|   Because inetd does work.  This is easily demonstrable.  I invite you to
| connect to my ident port, for example.
|
|   Perhaps you meant that inetd performs poorly under some circumstances? 
| Or is undesirable for some other reason?

Perhaps we're not talking about UNIX, but rather BeOS, which neither
supports the functionality required for inetd, nor is in any way intended
to be used as a network server.  So, yes, something like that.

To recapitulate, the original poster thought it might be nice to have
an SMTP and POP3 service for his site, which hosts himself, his spouse
and one or two children, on BeOS.  He has experimented with commercial
software, but for whatever reason thought it might be interesting to
try a Python implementation.  Before setting out to write it himself,
he asked - precipitating the most ridiculous thread you ever saw -
whether anyone had already done so.

|   Indeed, merely using non-blocking sockets is a little feeble, I'd much
| rather use kqueue or even AIO - maybe someday soon these will be available
| both on a platform that is in widespread use and to software written in
| Python.
|
|   select() is still better than threads, though (I feel no need to qualify
| this - we all know that very few things are *always* true).
|
|   One could take the time to re-implement all the required support code for
| an asynchronous application, or one could simply use tools already
| available.  Or will you argue that no such tools exist? :)
|
|   Threading ties you to an arbitrarily low number of clients - many popular
| operating systems can't even scale past a thousand running threads.  Though
| some platforms seem to be moving beyond this limitation, they're not quite
| there yet.  Threading also introduces such problems as deadlocks, race
| conditions, and resource starvation, problems which can be avoided, to be
| sure, but only at a significant cost in developer time.
|
|   You might argue that these can be avoided by proper use of thread-local
| data and properly protected access to what very limited shared data is
| allowed to exist, but one might also argue that this design is equally
| suited to a fork()'ing application that uses IPC, or better still, one which
| runs multiple processes independantly (maybe on different machines) and
| communicates via sockets.
|
|   Or is this wrong, too?

Only in this particular context, where forked processes don't inherit
sockets and the development effort targets a 3 user site.  I suffer
from a multiple personality disorder, in which one personality programs
on BeOS and finds threads acceptable and natural, and the other programs
on UNIX and avoids threads like the plague.  Personality 2 agrees
emphatically with everything stated above.

	Donn Cave, donn at drizzle.com