[Twisted-Python] twisted.protocols.telnet or twisted.conch.telnet?

glyph at divmod.com glyph at divmod.com
Sun Mar 19 23:13:12 EST 2006

On Sun, 19 Mar 2006 18:32:31 -0800, James Schend <blakeyrat at gmail.com> wrote:
>Well, if this is a library that you expect people to actually be able
>to use in production software, I hope that you take what I say under
>some consideration.

Many of the people using Twisted in production, and there are many who are, contribute to its maintenance in some way.  It is still a project actively under development.  However, it's hardly a necessity, and probably half of the people on the Success Stories page have never contributed anything to Twisted.

It sure would be nice if it were totally stable and full-featured, but it would also be nice if I had a pony.  There is a difference between not having the kind of total stability and commercial-grade support guarantees that you want (for free) and being unusable in production.  Code which is *way* worse than Twisted, with less maintenance and security attention than Twisted, is used in "production" all over the world, every day.

By the way, there are definitely people who *will* provide commercial-grade support for Twisted, any version you like, for a very reasonable fee.  My company (Divmod) is among them.  Unfortunately for us, it turns out nobody actually needs commercial-grade support for Twisted, because the code actually stands on its own pretty well :).

>One of the reasons to use a library, from my perspective, is that the
>interfaces can remain constant while the internals can be patched to
>ensure there are no bugs/security problems.  For instance, when libpng
>had that buffer overflow last year, that single library was updated to
>correct the problem without affecting the functioning of any of the
>hundreds of programs that used it.

libpng's interface is hardly stable.  There is a libpng, libpng2, and libpng3, and a planned libpng4.  The interface changes every major release.  They may not write "deprecated! unstable!" all over version 2, but I bet if you were to ask a libpng developer which version you should use to write new code, they wouldn't say "use the one we wrote five years ago and haven't been able to update except for security reasons".

Granted, libpng provides better support for side-by-side installation of mutually incompatible versions than Twisted does, however, it also doesn't provide any "soft" interface changes, deprecation warnings, etc.  It just totally breaks the ABI every major release.

Now, you could easily talk about the merits of sustained parallel development tracks and side-by-side installation, but I don't think that this is a worthwhile discussion until someone is actually going to provide the resources to *do* it.  The best you can do right now is discourage and annoy the people who are dealing with maintaining Twisted's *one* sustained track of development.

>It would be nice if the same could
>be done with Twisted but, as there is not currently a stable interface
>to it, that is impossible.

This is just FUD.  There is nothing magical about the word "stable" which makes security patches possible.

If there are critical security bugs in Twisted, it may well be in someone's interest to do a maintenance release of each release-branch which is used in production.  There is nothing about having a "stable interface" which makes this easy or free.

>I appreciate the work you put in to Twisted, but I'm sure I'm not the
>only developer who feels this way about it.

The sort of security problem you are concerned about is literally so rare that it has never happened before.  Twisted's security bugs (2 in its 5-year history) have always been caught well before another major-version release has happened.

I'm sure other developers feel the same way you do, and that's unfortunate, but you will pardon me if I don't immediately re-configure Twisted Matrix Labs' priorities around an eventuality that has never happened and may only hypothetically happen in the future, simply because it concerns you.

>At the bare minimum, you probably should deprecate an interface until
>there's something stable to replace it with.  I wouldn't consider a
>library with *no* stable interface whatsoever "well maintained,"


  deprecate \dep"re*cate\ (d[e^]p"r[-e]*k[=a]t), v. t.
     To pray against, as an evil; to seek to avert by prayer; to
     seek deliverance from; to express deep regret for; to desire
     the removal of.

When things are deprecated, it is a statement that we now understand that approach to be a bad idea, which we regret having implemented.  They may not be deprecated in favor of anything, or they may be deprecated in favor of something that isn't a part of Twisted (for example, the components system was deprecated in favor of Zope  Interface).  Sometimes, a particular API is just trying to accomplish an impossible task, or provides a bad way to structure code.  The first iteration of twisted.cred comes to mind.  Nothing attempts to do what the first version of twisted.cred did; the new cred has a much more restricted goal, because what the first version of twisted.cred was trying to do was nearly impossible and it turned out that it didn't actually work.

There was nothing stable in the telnet code in the first place; it just wasn't properly annotated as such.

Something being "well-maintained" within Twisted means that there are people working on it and actively interested in improving and advancing it.  To some extent, that is actually the *opposite* of stable; stable things are things that mostly work OK already.  It is possible to be both, of course. Some stable things, like the reactor, have a stable interface but a known-to-be-sub-optimal implementation, and the maintainers' work is being put towards improving just the implementation.  Those sorts of things are unfortunately rare, because interfaces turn out to be harder to get right than implementations.

More information about the Twisted-Python mailing list