Since I'm now syndicated on Planet Twisted, I suppose I had better say the occasional relevant thing.
In addition to my main presentation (on the Divmod-developed technology, ATOP) I've got some ideas for either lightning talks or open-space sessions (depending on level of interest) I might do in dull moments at PyCon. Does anyone want to hear one of these?
- The Long Hard Road to Zope
An exploration, with heavy audience participation, of why everybody writing sufficiently complicated code in Python ends up rewriting every major aspect of Zope one at a time (object database, component model, asynchronous networking base, thread pool, web templating language, not necessarily in that order) but Zope itself is difficult to use and so routinely critcized by the community despite also being widely loved and touted as an example of Python's power. I'd love it if this could include some feedback from the Zope folks about how Zope can be integrated into these ad-hoc environments when you "really need the whole thing", how to tell when you really need the whole thing and when a partial solution might be more appropriate. - Disassembling Twisted
I want to break Twisted into lots of different pieces. Currently there is a huge amount of coupling between packages: if someone makes a problematic, compatibility-breaking change in CVS head, it doesn't matter if that change is in a horribly obscure place, it blocks a whole release, bumps a major version number and prevents all packages from being released until it can be tested on all platforms, fixed, stabilized, etc. I believe that the Python core has similar problems (and possibly more ideas for solutions) with its increasingly sprawling standard library and extremely slow major-version release cycle. On the other hand, neither the Twisted or Python Core developer communities are fairly small, so we need to be careful not to burn resources in complicated release procedures. Also, the "batteries included" philosophy has helped both Twisted and Python quite a bit, so we need to explore separating releaseable chunks and still having a large, integrated release which makes it easy to assume that lots of functionality will be available if Twisted is installed without mixing and matching a bunch of little pieces. - Network Hostility Management
How hard is it to build a system which would send arbitrary files from any network-connected computer to any other on the internet? How much help do you need from servers on the "real" internet? Most importantly, to what extent can you hide all the nasty details from the user? I would like to outline and discuss a file-transfer tool which can defeat as many kinds of firewalls as reasonably possible without being a security hole itself that firewall admins will attempt to close off. - Quotient Infrastructure
A discussion of the "big picture" when it comes to Atop, Nevow, and Quotient's app-server-like components, for those of you who have attended both DP's and my presentations. Discussion (and hopefully delegation) of separating application and infrastructure. - Component Model Experimentation
We're still tweaking the semantics of Twisted's component model, but obviously this has the potential to break a good deal of client code if we release changes. How can we map the core set of semantics that most people currently care about onto a potentially changing back-end? - Twisted Imagination
Either this is your life's true purpose or you just don't care. I would like to talk about maybe, you know, writing a working game this decade.
I can think of a few more ideas, but this is probably enough for at least two conferences. Thoughts?