Ian Bicking: the old part of his blog

Turbogearsandpylons comment 000

TG has looked into replacing CherryPy with RhubarbTart (a WSGI compatibility library for CP's dispatching model and global variables). Could a Paste- or Pylons-ified version of RhubarbTart be written that TurboGears could sit on top of?

RhubarbTart is very Pasty (I helped write parts of it, so that was inevitable ;). It also provides a surprisingly good story for CherryPy 2 compatibility -- some of it involves some messy monkeypatching, but it works. (During the sprint at last year's PyCon where we tried to use RhubartTart instead of CherryPy, we tried to avoid changing TurboGears too much, and TurboGears applications at all -- instead extending RhubartTart.)

Some of these hacks could be maintained or ported to Pylons. There are some other differences; for example, RT uses a request object modeled very directly on CP's. However, the Paste/Pylons request object does not require exclusive access to the environment, and multiple request objects with different APIs can coexist. There's also the dispatching system. Right now there's not really alternate dispatching systems for Pylons, but there could be, and RhubarbTart's could be ported over. Especially if you are comfortable depending on @expose (a different implementation than the current TG one with the same interface), that could be a very cleanly implemented alternative to Routes (RhubarbTart uses CherryPy's mechanisms, which rely on a more limited interface than WSGI).

Something like RhubarbTart-on-Paste could hide the WSGI dictionary that is so offensive to some people.

paste.wsgiwrappers.WSGIRequest already pretty much does that, so it's fine. They just chose to put of the strawman of the low-level functions in paste.request to argue against.

Making a config format is hard: both TG and (I think) Paste have switched back and forth between INI format and Python format (or the hybrid Python-with-section-headers format). Each has some advantages and disadvantages.

Early Paste used Python files for configuration. IMHO this worked quite poorly. Using Python expressions is much more reasonable (which is what CherryPy and TurboGears do), without the full generality of Python statements, conditionals, etc. Generally if you need really complicated configuration, I suspect you are doing your configuration wrong -- configuration should be a deployment concern, not something where you implement complex glue. The glue in a typical Paste applications still goes in Python files (e.g., middleware.py in a Pylons project). If that glue process needs to be informed by configuration values, you have the configuration and can glue stuff together based on that -- but providing a higher-level and domain-specific set of configuration values that effect that.

I wish I could declare ints and dicts directly in a Pylons config file. But the opposite position sees too many quotes and braces. Perhaps Paste and Pylons could one day support the hybrid format as an alternative. Of course this means type conversions would have to be pushed to a lower level when using Pylons INI format: right now they're done in the application code, and this would fail if the values were already converted.

At least most Paste-style conversions accept non-string values. It's really that when you do get a string value, you should treat it as though it's a config value. So 'false' is a false value (where in Python it would normally be true, since it is a non-empty string). So if you wanted to build a config format that accepted those values (and still used the Paste Deploy APIs, which are fairly config neutral), it would work. Of course, if you depend on that in your application you will be incompatible with simpler APIs.

It would be very reasonable to build another config file format that used Paste Deploy's APIs, but not its exact config format. Something more path-oriented (that natively supported urlmap) would be quite feasible, for instance.

Neither format supports nested sections, if you ever want that.

They both support nested keys, like component.key = value. Paste doesn't specially interpret those values (it's up to the consumer), while CherryPy does. When an application requires more structure in its configuration I usually use expressions in the keys.

Both Pylons and TurboGears need a CMS to fully compete with Django and Zope/Plone. This is a big task, and one which both communities could work on and perhaps create a common package both could use. One issue is whether this could be implemented purely as middleware or whether it would have to interact too closely with the application.

A CMS is a very vague thing. It means different things to different people, and any large website feels a lot like a CMS.

I think relying on HTTP, REST, and middleware, you could very possibly make CMS construction easy. For instance, AuthKit could be expanded with a full user system. You could make a pluggable authorization middleware where you could restrict and manage user's access to areas of the site. An event notification system could be constructed where you could notify a central component about the existence or deletion of pages, thus allowing a navigation system to keep track of what's on the website. Things like paste.cascade can be used to fold a CMS in with dynamic applications (like a shopping cart), while programmatically-driven layout (again using the Paste Deploy APIs, but not config format) could allow local "plugins" to be added (like a checkout, forum, etc).

But focusing on the big "CMS" will make this hard, because it's too big and too vague. Focusing on specific problems you want to solve and using some of the concepts of reusability that Paste encourages (like WSGI Framework Components) will build up the pieces you can use later.

Comment on Re: TurboGears and Pylons (a technical comparison)
by Ian Bicking


By CMS I specifically mean the workflow of one person editing a document over several sessions, others possibly previewing it and correcting it, and then clicking something to make it visible to the public. Enhancements include a rich Javascript editor, talkbacks, gathering articles into magazine issues, adding article metadata, etc. We have the parts for all this, but some users rightly want it to work out of the box, and will skip over TG/Pylons to Plone if they don't have it. Unfortunately Plone is in its own little world and depends on Zope 2, making it more difficult down the road when you want to combine the site with non-Plone tools.

Security is a relatively straightforward problem. Articles have roles (author, editor). There will have to be some map of users to roles ("editor for all articles", "author for this article"). Then the authorization code just has to enforce it.

# Mike Orr

It's true webservice will grow spread our posibilities. But it makes things more breakable. I'm not sure how to prevent the internet from getting instable...

# illy