[Twisted-Python] Proposal: changes to reactor.clientTCP

[Glyph Lefkowitz]

From: Tommi Virtanen <tv at twistedmatrix.com>
Subject: Re: [Twisted-Python] Proposal: changes to reactor.clientTCP
Date: 21 Jun 2002 22:04:08 +0300

> Allow portable programs to get a "sanitized version", but allow my POSIX-only
> programs get errno. For what kind of sanitization one might want, you
> probably want to look at the man page for say connect(2) for all the possible
> error cases, and categorize them based on local/remote, temporary/permanent,
> etc., and create a "high-level error" for each class, with perhaps the string
> corresponding to the errno as extra info meant for users (and not if
> statements).

> But please do _not_ loose any information in the translation.  Say people
> shouldn't look at the error objects errno attribute to decide what to do, as
> not all platforms provide it. But don't hide the actual error.

Upon consideration I strongly agree that no information should be lost.

So, let's have such a high-level error, and a .platformError attribute on the
connection error object which is an object specific to the "OS" that you're
running under.  On POSIX this will be (or contain) an errno error code, but on
Jython and elsewhere it will be whatever's appropriate.  Does that work for
you?

> Remember my background; I'm a kernel hacker, and I know the UNIX libc/kernel
> API. If I run a program that tries to e.g. connect with TCP, and it fails
> without giving me a good reason, I _will_ run it under strace -e
> trace=connect just to see whether connect failed, and with what
> errno. Operating systems without BSD sockets just aren't, and I write my
> programs to use fork anyway. My point -- don't decide for me, let me decide
> on my own.

The reason I'm resistent to this is that I would like to encourage writing
portable programs with Twisted, especially in cases where platform specificity
doesn't add any functionality.  On the other hand, I don't want to be Java here
and try to _force_ programmers to write their programmers in a portable way
when they really know better than I do what they want.

Problem is, programmers rarely know what they want.  For example; if you're
using Twisted, why use fork?  You ought to be using reactor.spawnProcess for
non-portability-related reasons anyway; Python's refcounting doesn't work
reliably with COW memory.  Of course, there are reasons not to do this; of
course, there are times when you just _need_ to get down to the OS and do
something in a very, very platform specific way (sometimes even specific to
your particular OS vendor, not just POSIX).  This should not be the default.

Handling an errno error code specifically should also be considered a *very*
esoteric operation.  I personally can't come up with any need to use it except
debugging under a particular environment; I would far rather that people used
to the POSIX API learned how to use the Twisted APIs to do POSIX-y things, so
that their programs would be more portable.  

Balancing this with the need not to piss people off is difficult :-).  I can't
think of a way to say "DON'T USE .platformError UNLESS YOU REALLY NEED IT,
WHICH YOU DON'T" without making everybody read the documentation, which they
won't anyway.  I can imagine many programs made non-portable by someone looking
for the answer to the question "how do I find the errno of what happened"
rather than the correct question "how do I handle a connection error".

So I guess I'll provide the platform specific information and put my faith in
the worldview of applications programmers; please try to give them good
examples to look at :)


-- 
 |    <`'>    |  Glyph Lefkowitz: Traveling Sorcerer   |
 |   < _/ >   |  Lead Developer,  the Twisted project  |
 |  < ___/ >  |      http://www.twistedmatrix.com      |
-------------- 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/20020621/254e5b2f/attachment.pgp