Compound Thinking

Two views: What are “designer friendly” templates?

TurboGears and Django both call their template languages “designer friendly” — but they are not saying the same thing..

Django’s templates are not particularly Dreamweaver (or other WSYWIG editor friendly), and Genshi (like it’s older brother Kid) isn’t designed to be particularly easy for graphic designers to learn.

As far as designer-friendliness goes, I think it all comes down to workflow, and what you expect designers to do. If your designers work in Dreamweaver, and want to be able to look at the template files there, Kid/Genshi’s attribute based markup language will be the most likely to hold up to changes they make. But, if you work with with the same designers over time, and you have designers use text-editors to edit HTML and CSS are willing to learn a few simple markup tricks, the Django template language starts to make a lot of sense.

The Genshi system works well with WSYWIG tools, and allows you to write your pages so that they preview well in Firefox and IE — without the need for a server. But, it’s also less likely that designers will want to learn how Genshi works (don’t get me wrong, I know lots of designers who know Genshi, I just expect that the Django people are right in arguing that their template system is more accessible to non-programmers). So, you’re likely to have more programmer involvement after the designer does his/her work if you use Genshi.

But it is worth mentioning that modern CSS based layouts actually make it much, much easier for programmers and designers to work together without trudging all over one another’s HTML. This means that good design means that look-and-feel changes can often (but not always) made without ever touching the template. This change actually makes a lot more difference in “designer friendliness” than which template language you choose.

Of course there’s more to template languages than “designer friendliness,” and the differences between TurboGears and Django become more apparent there. Topics that should probably be discussed at some point are: cross-site-scripting attacks and HTML/XML auto-escaping systems, the value of template-sandboxing vs trusting your template designers, and the need to produce lots of different kinds of XML (RSS, Atom, etc) and how template languages fit in. Oh, and I should probably talk about performance issues too. But, that’s way too many hot-button issues for one day.

So, I’ll leave those controversies for later. ;)

Multi-Process TurboGears deployments

Cliff Wells wrote a blog posting a while back about load balancing a TG 1 app using nginx. This deployment senario has worked out really well for me.

Apache is everywhere, but nginx is much less memo2ry and CPU intensiveparticularly under very high loads.
I think both Mod-WSGI and nginx deployment scenarios are both vitally important to the future of TurboGears (for different reasons) and we ought to have good recipes for both on the TurboGears Docs wiki, but that’s a blog post for another day.

There was a bit of confusing FUD about TurboGears out there on the mailing lists last week. The author of this FUD once again seems to have gotten confused, and was telling people that TurboGears multi-threaded deployment model was inherently limiting as opposed to a single-threaded multi-process server model.

Here’s my basic response: Just because you can have more than one thread per process doesn’t mean you can’t also have more than one process.. And that’s exactly what high-volume turbogears sites do they run multiple instances behind a load-balancing proxy server.

In general threads are hard to to get right, but in the context of a web server with a thread-per-request model, things aren’t actually that hard. And threads are nice because they don’t block the whole process during network or database IO, and they take up a lot less memory than a new process. So, if you have 50 processes with 20 threads each you can handle 1000 concurrent requests with a lot less memory than if you ran a separate process for each of those 1000 requests.

As for how many processes to use on your production server, that all depends on your app, but I have noticed a pattern in several in several different load tests on several different TurboGears apps, written by several different clients. In general about 4 processes per CPU seems to be the sweet spot.

But the nice thing is that the CherryPy web server is fast enough that a lot of sites just don’t need to run multiple processes to handle their traffic.

TurboGears 2 tutorial at Pycon

PyCon Registration is now open, and I’d like to take this oportunity to mention that
Ben Bangert and I will be doing a set of joint Pylons/TurboGears 2 tutorials at Pycon this year.

The tutorial materials have been designed not just to help people use these web application stacks, but to understand how they work, and what happens “under the hood” so to speak.

We’ll be covering everything from WSGI to automatic CRUD tools, and will introduce you to all kinds of new stuff. Pylons and TurboGears are designed to scale down to very simple application’s, and up to the point where you can easily have multiple databases, application servers, and huge numbers of daily page views.

And, of course we’ll give you the low down on how the two frameworks are the same (they share huge swatch of code) and how they are different. It should be a rip-roaring good time.

Wow, a billion dollars for MySQL

Apparently Sun thinks MySQL is worth a billion dollars. I still prefer PostgreSQL, but unfortunately I don’t have a billion dollars lying around, either.

Good thing they are both open source!!

Important TurboGears 1.x Security Notice

Most TurboGears users are not effected, but all TurboGears users who have explicitly added CherryPy based sessions to their application are subject to an important security vulnerability.

Malicious users could create a specially crafted cookie that could delete files beginning with your SESSION_PREFIX from your file system, add new files with that prefix, or overwrite files with the same prefix with arbitrary pickled python objects.

All such users can re-secure their system by updating to CherryPy 2.3.0.

Again, most TurboGears users are not vulnerable to this issue, and do not need to update their systems, you are only vulnerable if you have specifically enabled sessions with:

sessionFilter.on = True

in your configuration file.

You can also search for calls to cherrypy.session in your application. If you find either of these things in your application you are potentially vulnerable, and should test your application with 2.3.0 which should be backwards compatible with your existing turbogears app.

The easiest way to secure your application is to easy-install it via:

easy_install -UZ "Cherrypy==2.3.0"

You can use the “tg-admin info” to check what version of CherryPy you currently have installed. Please do this before you attempt to update, so that if anything goes wrong you can rollback to your earlier version of CherryPy with:

easy_install "CherryPy==YourVersion"

Once the update is complete, be sure to use the tg-admin info command again to verify that you are in fact using 2.3.0, and don’t forget to restart your server.

We have released new versions of TurboGears, with this updated dependency. So, you can also upgrade TurboGears to 1.0.3.3 (the most recent stable version), or 1.0.4b5 (the most recent beta), and all new TurboGears installs will not be vulnerable, even if they do turn on cherrypy.session.