Composing WSGI Apps

Ian is writing about what can be done with Paste already in Composing WSGI Apps.

and based on what I wrote back in April ( 42: Designing from the Outside In) thinks I am feeling enthusiastic.

Well actually more than that. I am now really excited (not sure quite how you compare these on a scale, but it is better). Recently I have been getting more involved in Leonardo (which I have written about before a few times). That work has mostly been on supporting the Atom 1.0 specification.

There are some really good moves for Leonardo. One is that the Atom 1.0 provider will be a plugin (hopefully the first of many) so we are looking at a whole range of new python tools such as eggs and EasyInstall to make this possible. With plugins Leonardo becomes a hugely flexible yet lightweight combination of wiki and blog making it a super content management tool for small sites.

Another is that in the longer term some of the cooler Leonardo technologies such as it’s Local File System and Formatters are likely to be packaged to be available as eggs for other projects to use.

I think it is also fair to say that Leonardo is going to be moving to using PythonPaste as it’s default runtime environment, that makes interoperability with other python applications much easier.

One of the ideas I have is to use AJAX techniques to pull content from other python mini applications into Leonardo pages. For example if I have a Church website done in Leonardo then I could use ajax to pull the list of services in from a simple database via a CherryPy application. That way the page stays up-to-date and my site becomes a web of loosely coupled pieces. We can then build up collections of small Python applications that can be integrated at the view level using Ajax (as they are all running inside the same server namespace).

As WSGI implementations continue the hosting options are going to mushroom with a wide variety of horsepower from the simple cgi through to whichever combination of multi-process or multi-thread suits your needs best.

3 thoughts on “Composing WSGI Apps

  1. James Tauber

    With you all the way, but I would add that some of the integration you are talking about with AJAX, I was thinking could be server-side as well. i.e. some providers could get their information from sources other that LFS, like other atom feeds or databases.

    Reply
  2. Ian Bicking

    Paste’s recursive middleware would help here: http://svn.pythonpaste.org/Paste/trunk/paste/recursive.py
    You would do something like:
    includer = environ['paste.recursive.include']
    response = includer(‘/path/to/other/app’)
    response_body = str(response)
    This will make a simulated (or internal) request to that path (relative to the SCRIPT_NAME of wherever the recursive middleware is installed). It’s a lot like Apache SSI’s, where you can include a “virtual” path, which does an internal request and returns the body of the response.
    One easy way to make that available would just be to put the includer object into the namespace for the template, and then your template can do a recursive call.
    Also, while WSGI-level caching isn’t very granular, this could be granular. That is, you could cache internal requests that make up the body of a page, and save on some work. There isn’t any caching middleware for Paste yet, but that’s definitely something I’d like to see happen at some point.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>