Well, that’s a long comment. I’ll answer it starting from the end.

I never said that Nevow is poorly designed. As for Twisted, well, I’m out of that argument. You don’t have to believe my judgement, go and look by yourself in its sources.

Now, regarding your judgement about Allegra:

>It is about as inventive as CherryPy and totally inferior in execution.

I have no problems accepting that critic of the incomplete web framework bundled with the library. To encumber Python with yet another LAMP framework is not Allegra’s purpose. The objective here is to deliver a distributed and statefull application server backed by an innovative metabase.

About Nevow’s general design itself, I find it rather good (although what you say about traceback is more than annoying, for me bad tracebacks in a framework are definitively a show-stopper).

Yet, Nevow is not so much better and rather less complete than what is available from Django and other widely adopted LAMP stacks. So, however good the design is, that won’t make a difference: adopting Nevow still comes at a high risk and brings little if no benefits.

Last, but not least, I don’t really understand how Nevow can be deployed without Twisted. It’s application server requires it:

http://divmod.org/trac/browser/trunk/Nevow/nevow/appserver.py

And the README is quite clear about what you can do without Twisted:

http://divmod.org/trac/browser/trunk/Nevow/README

“Before installing Nevow, you should install `Twisted`_, unless you are going to write very simple CGI applications. Nevow integrates fully with the twisted.web server providing easy deployment.”

Thanks for reading,

Nevow deploys easily without Twisted. It has some very real advantages
in that it allows fast implementation of web web support in a
way that has some very clean and elegant separations. Fully
validating XML in templates is one advantage. Mixing Stan and
Python list comprehensions and generators is more powerful
than anything I have seen in any other web framework.

And adoption is wide scale enough. There are some people,
including me, who are building mission critical systems
with Nevow. We won’t let it go away.

That said, there are two things that are bad with Nevow.
The first and most serious one is that tracebacks seldom
say anything about where your error actually occurred.
This is really bad, but I still find the advantages of using
Nevow to outweigh this problem. The second is that Nevow
has been written by a person who is too fond of writing
tricky code to save bytes. A more conservative coding style
would increase the readability of the code and increase
the chances of getting contributions from others.

But claiming that Nevow and/or Twisted are poorly designed,
that’s just hogwash and says a lot about your judgement.
(Due to your previous mudslinging at Twisted, I had a look
at your own efforts at building a web framework and I was not
all that surprised at finding it to be lacking. It is about as
inventive as CherryPy and totally inferior in execution.)

Hmm, I suppose that one is ironic.

Well, for the record, I don’t hate Twisted or its Minions.

Actually, at first I thought that competition would bring benefits to both projects. And it did bring me some when I reviewed Defered vs. Finalization. But as I scratched deeper in Twisted sources, the argument worsened. Peer review turned into some kind of religious war … on their side.

And I was just horrified at so much fanatical superstition.

So, I decided to poke fun at their sacred cow along my serious criticisms. And, as we all know, if there is one thing that zealots can’t take, it’s a joke.

Or a cartoon.

Steve Holden accused me of “polution” in the Official Planet Python.

By the way, that’s how I noticed that the Elders of Python had included my blog in their prestigious list. Thank you Steve!

Now Chuck want’s me out of the Effbot’s daily Python URL.

Censoring the judgement of Frederik Lundh and Python’s webmaster is what those guy are calling for. When people turn to censorship, you can be sure that what is said does ring a bell …

Thanks for reading,

At least you agree that gzip Transfer-Encoding is not implemented. Which was indeed precisely what I was talking about: protocol encapsulation.

Can it be implemented independently from the HTTP channel?

I mean, without adding code to the methods of the HTTPParser class in

twisted/web2/http/channel.py

As for Multipart MIME decoding I finally found it:

http://twistedmatrix.com/trac/browser/trunk/twisted/web2/fileupload.py?rev=17295

But why does it require all that bizarre stream machinery and … defered?

Would it be because there is no other way out of the dependence on the event I/O loop?

Compare all that complication with the simplicity and elegance of asynchat’s original producer and collector *encapsulable* protocols. Have a look at Medusa’s original implementation of Chunked-encoding. Or Allegra’s for that matter:

http://svn.berlios.de/svnroot/repos/allegra/lib/http_reactor.py

That’s what is possible when the readable/writable couple is available.

Can you see the light?

Regards,

I only wrote most of the sources, I guess I don’t actually know what I’m talking about. You have the worst habit of taking random comments in the source and making a big deal of them without really understanding what it is you’re talking about. That comment must be read in its context: that is, implementing transfer-encoding. And, yes, gzip Transfer-Encoding isn’t supported. But you weren’t just talking about Transfer-Encoding. Content-Encoding: gzip is supported. And that’s what is needed most of the time. TE: gzip isn’t widely implemented in today’s web browsers, so I haven’t bothered to implement it. That’s all.

So, no, I won’t trust your word for it. Sorry.

Thanks for that comment. I too prefer to produce technical documents like

http://laurentszyster.be/blog/async_client/

rather than this endless argument with Twisted minions. But somebody has to say the naked truth about it, or we’ll end up with Ruby on Peers instead of Python.

However, I have to admit it, you’re right: I have a bad attitude.

So, I’ll try to amend myself and tone down my criticisms as much as humanely possible when confronted with superstition.

As for the licencing issue, if the GPL does not suite your needs, you can still buy me a commercial licence (the MySQL way). That’s what profitable frameworks are made for: develop software that sells with profit.

If you have a great application in mind and customers willing to pay, why would you not share some of your profit in exchange of what Allegra can offer you.

Less risks and more benefits for your network peer applications.

Regards,

> twisted/web2 has support for gzip and multipart and url form encoding.

Have you read the sources? Do so:

http://twistedmatrix.com/trac/browser/trunk/twisted/web2/channel/http.py?rev=17295

and make sure you check those two lines:

268 # TODO: support gzip/etc encodings.
269 # FOR NOW: report an error if the client uses any encodings.

Twisted developers have a bad habit: they don’t read their own beloved sources before making wild assertions. The new twisted/web2 do not support gzip and I did not find a multipart mime implementation either. And if, some day, such implementation arise in those Twisted sources, it will not be encapsulable.

The reason, if you care, is that it is impossible to do so without decoupling both protocols and transport from the I/O event loop.

If you don’t understand why, if you don’t trust my word, confront the fact: in 2006 there are no encapsulable independant protocol implementations available in Twisted.

Why?

Medusa had them … ten years ago!

I just marginally improved them:

http://laurentszyster.be/blog/async_chat/
http://laurentszyster.be/blog/collector/
http://laurentszyster.be/blog/producer/

with the ability to stall both way. For peers.

Regards,

I liked the documentation series of articles on the blog, and the quirky pictures are a nice aesthetic touch. asyncore is so much simpler to get a handle on than twisted, and it actually works with stackless whereas twisted does not. But the twin dragons of the GPL and your attitude have turned me off completely. Now it’s not enough to grind your axe at twisted, you have to start in on nevow (which incidentally has one of the best TAL-like template languages around). I suppose it’s still enough of a technical achievement to warrant interest, but I do wish that Python-URL would stop automatically publishing these flaming missives of yours.

> I still don’t see what’s wrong with Twisted.

The core of the network I/O library is broken:

http://laurentszyster.be/blog/back-to-the-future/

Twisted is “wrong” in several other ways (see my Twisted Bits article), but the most significant is that there is an IOC couple gone missing, which makes it impossible to develop encapsulable stream protocols.

And that’s a requirement for a *productive* internet peer programming framework.

Practicaly, due to a common dependency on the I/O event loop in both Twisted transport and protocol implementations, it is impossible to combine diverse complex stacks of stream protocols with Twisted.

Like for instance:

HTTP + Chunk-Encoding + Multipart-Mime + XML

or

HTTP + Gzip + url-form-encode

Which is why twisted/web2 only implements HTTP + Chunk-Encoding, but can’t get any much further without expanding the sources to unmanageable size and complexity.

If you really need the scalability and performances of libevent, can handle the common dependency on I/O events and don’t care about stream protocol encapsulation, go for the real thing, and directly develop on libevent’s Python bindings.

Regards,

Nevow is a completely different story. dp and the gang are _very_ supportive and helpful.

And I still don’t see what’s wrong with Twisted.

First, let me remind you that sex is good (wether it’s straight, queered or B&D games, at least we’re having some ;-).

Second, can you give more substance to your critics of Allegra?

> less mature

Allegra is forked from Medusa, a 1996 code base which has been in the standard Python lib since then. Calling it less mature is childish at best.

> less functional

If this means that Allegra does not support every GUI event loop on earth and rare protocol of dubious application in Python (like PTCP), well that’s true. But those functions are hardly features …

Can you explain why and how Twisted does a better job than Allegra solving the five main issue faced by any network peer application developer:

1. asynchronous continuation
2. decoupling of event, protocol and transport
3. flexible protocol encapsulation,
4. thread synchronization
5. network user interface

Or is there something irrational preventing you to question the sacred scriptures of Glyph? Those “things you believe in but don’t understand …” are called superstitions.

Where I agree with you is that I’m not a “kind, loving, lead developer”. First because at the moment I’m leading no one than myself. Second because, it’s true, I’m mean. With code.

Regards,

First this article is not a rant. It’s a short explanation of what could possibly restrict the popularity of Nevow as a web framework. Now, as allways, when somebody dare critizice Twisted sacred cow, we’re in for a flame.

To Fuzzyman:

Hi Voidspace Techie!

There are moves “in progress” to factor the core out of Twisted and into the Standard Python Library?

As far as I know, there are not. It was discussed:

http://www.python.org/dev/summary/2006-02-01_2006-02-15/#asynchat-and-threads

“Mark Edgington presented a patch adding “thread safety” to asynchat. Most people seemed to think mixing threads and asynchat was a bad idea, and the thread drifted off to talking about exracting a subset of Twisted to add to the stdlib (as a replacement for asynchat and asyncore). People seemed generally in favor of this (if the subset was reasonably small) but no one stepped forward to extract that subset.”

Would you volunteer?

To Antoine:

Je n’ai pas d’autre objectif que la promotion de Allegra. Et je pense sincèrement que mon effort de documentation:

http://laurentszyster.be/blog/allegra/doc/

apportera à ce projet plus de crédibilité et d’attention que toutes les critiques de Twisted.

Néanmoins, il s’agit bien de deux projets concurrents, ce qui implique la critique comparée. Qu’elle soit insupportable aux zélateurs de Twisted et suscite autant de commentaires péremptoires mais vides de faits, voila qui en dit long sur la qualité des développeurs de ce projet.

To Steve:

The Twisted community is anything but “fearsomely clever”. Quite the contrary, it is fearfully superstitious about its own sources. Which the vast majority of the sect has never read.

No wonder: it’s so obfuscated by layers of (useless) indirection that Glyph can deny what he wrote:

http://laurentszyster.be/blog/ioc/#comment-610

and none of his zealous followers will ever notice.