So Nevow and Athena are indeed great, and Twisted doesn’t get enough credit, but at this point it’s becoming easier and easier for “mainstream” developers to turn to whatever async network responder layer is built into the environment they’re already invested in. Jumping into Twisted, esp pre-Abe’s book, required not only being familiar with Python, but also seeing enough value in async network programming to put up with the pseudo-CPS-style idioms that Twisted grafts onto the language. For folks who know they need Twisted, it’s a no-brainer, but for a lot of other people the stumbling blocks that Cliff points out prove to be insurmountable.

All of this is just to shed some light on why the name “Comet” and the Bayeux protocol are necessaray: most people really can’t recognize the value until they can recognize the problem. Hopefully the “Comet” moniker will do good things for Nevow and Athena adoption, but part of the battle there is also in helping users to recognize the problems that the framework solves. Documentation, live apps, examples, and a community that believes passionately that they are doing thing the right way will help that a lot, but right now there’s not a lot to hang your hat from if you’re a Nevow/Athena developer.

We’re developing twisted-cometd on top of Twisted Web2 today, and I’ve gotta tell you that I’ll probably be recommending the Jetty or Perl implementations of the server stack because they don’t require being wedded to alphaware or to something that’s clearly EOL’d.

Regards

http://twistedmatrix.com/trac/.....ithTwisted

For the level of interest in the “one right way” to do web stuff in Twisted, we don’t really have very much manpower. Nobody is getting paid to solve this problem, and all the hyperactive teenagers with too much time on their hands who got Twisted started (myself included) are now working on rather time-consuming jobs at frantic startups, writing software for airlines or online services.

Any chance you know someone with some spare time? There are piles and piles of already-known issues in the Twisted and Divmod (e.g. Nevow) trackers that need working on…

The information on how to accomplish this might be there, but I doubt I’d be able to sort it out in any timely fashion (or properly choose between the usual state of “don’t use this because it’s deprecated and its replacement will be done real soon now”). I think herein lies Twisted’s reason for not dominating the Python webspace: any path one might choose outside the core (i.e. anything non-trivial) is either labeled “deprecated” or “unstable”. That’s not a recipe for successful marketing. Deprecate something when its replacement is ready, not a year beforehand. Microsoft has successfully employed this very strategy (FUD) against other companies for years and the Twisted community seems to employ it against themselves. What’s the “right way” to do something in Twisted? Apparently there isn’t one.

There seems to be a couple half-completed examples of a wiki and a blog on the Twisted site. If someone who actually knows the right way to do these in Twisted/Nevow (and could make them more prominent on the site) it would go a lot further than any marketing or hype might. The Twisted community being a little more savvy about outside developer concerns would go a lot further.