November 27th, 2012

Albatross 1.42

Albatross is a small and flexible Python toolkit for developing highly stateful web applications. The toolkit has been designed to take a lot of the pain out of constructing intranet applications although you can also use Albatross for deploying publicly accessed web applications.


Hold your horses, this review isn't complete yet.

This framework made me absolutely curious about it, due to it being advertised as a stateful web application framework. I initial read into it a few months ago, and now again, I have jumped back into it to explore how it worked and what it can do. This framework is a highly advanced framework, and lots of Python knowledge and experience is necessary in order to properly use it. Everything from the backend code to the template engine require some sort of Python knowledge in one form or another. The documentation is very confusing in the method chosen to teach the framework itself, and doesn't help as much as documentation should. The documentation doesn't fully explain lots of concepts, which I still scratch my head at, and the overall layout makes you either have multiple tabs open in your browser and jump around from page to page trying to find something out. In other words, parts of the documentation don't properly use Hyperlinks. The tutorial starts out with explaining the Template engine and going back to the days of CGI to explain the Theory behind it. The template part of the tutorial was actually rather boring for an experience Pythoneer such as myself. It then goes into how to build a CGI script that uses Albatross. There is very little explanation of how to use it in the Application mode, which the quick start explains. There is also no documentation for the INI file, which Application mode uses to configure itself. I ended up needing to search the source code for the various options needed. Actually, searching the source code to see how everything was glued together at times was easier than reading their documentation. Their documentation was not very helpful due to it's overall structure and organization, also the topics did not explain how to use each of the App/Context types included with the framework.

Okay, now that we have the documentation out of the way, lets talk about the actual framework and how it stands to the rest of the frameworks out there. Firstly, it feels outdated due to it not talking about a WSGI deployment option, and with the tutorial mainly explaining how to deploy in CGI mode. This doesn't do the framework much justice, as it is very capable once you see what it can do, and it definitely can create stateful web applications. These applications are more for your intranet application, or a public survey application where you need to control the exact flow.

This framework separates the session management into four contexts, these contexts are hidden-field, session-file, session-server, and branching-server. The first one, hidden-field, uses a hidden field in each form to pass the session information around. Since these are stateful applications, you will rarely be using hyperlinks and instead be using forms and submit buttons. This one will also work on browsers which block cookies, and can be ideal for public facing websites, such as a survey. The idea behind this one, is that if the end-user breaks the follow at any point in the transaction, they are sent back to the beginning. This also enables the back button to work in their browser as well, since the session data is not stored on the server. This way, you can continue to collect data from the user until the final form when the user is ready. The next methods store the session data server-side, and work otherwise the same as you would expect a server-side session to work. The very last one is especially interesting, since it can allow the user to press the back button and start a new session if another part of the application is started from there. This can allow for some very interesting applications to be created, applications which are aware of the user's history, and can also prevent submit mistakes which regular server-side sessions may cause.

After choosing a context, you will then need to choose a page type, this is much more confusing at first since the documentation doesn't seem to explain best practices or how to use the application mode. There are a total of three page models, they are simple, modular, and random. When you use the quick start guide, it uses the random type by default. This page type allows your application to work just like a regular website, but still taking advantage of the template engine. I don't find this type very useful, since if I were going to build such a website, I would use a regular framework. The simple page model uses Classes to store each page, which then need to be registered with the application. Most of the examples use this page type. The modular page type allows you to store each page in a separate file. While using the framework, I mostly used the simple page model, since I was not building anything very large. A part of the documentation explains how to convert an application using simple over to modular.

After using this framework for a few days and creating simple stateful applications, I can definitely see it's potential in multiple applications. However, it's deployment methods make it difficult to choose over other frameworks. The documentation only explains deployment methods specific to Apache, which will take extra work to make compatible with Nginx. If you have the time, you may wish to build a stateful framework into an existing web framework. However, if you require a stateful application done quickly, you may also want to look elsewhere... This framework can take time to master, and unless you already know it, don't expect immediate results. If you already know how to use this framework and need a stateful application, then by all means use this framework.


  • Supports stateful web applications
  • Can use form-only sessions, no cookies needed
  • Very powerful once understood


  • Confusing documentation and app types
  • No native WSGI handler
  • No dynamic URL routing


If your willing to take some time to learn this framework, and need to build stateful web applications in the future, this framework might be a good option. There are not many frameworks which provide a stateful web experience, and this may also be your only Python solution.

Package Website

About Me

My Photo
Names Kevin, hugely into UNIX technologies, not just Linux. I've dabbled with the demons, played with the Sun, and now with the Penguins.

Kevin Veroneau Consulting Services
Do you require the services of a Django contractor? Do you need both a website and hosting services? Perhaps I can help.

This Month

If you like what you read, please consider donating to help with hosting costs, and to fund future books to review.

Python Powered | © 2012-2019 Kevin Veroneau