Team Eiffel

Some years ago I discussed the architecture of ejax. I'll promise that this time the name of the framework won't start with an "e", although Eiffel on Rails is tempting!

The goal of ejax was to create small independent cgi applications: they are loaded fast, and that worked best with SmartEiffel, my Eiffel compiler of choice at that time.

Some years later SmartEiffel has gone, and ISE Eiffel and Gobo Eiffel are now the compilers to use. ISE Eiffel doesn't like compiling a lot of cgi applications though. The disk space consumption would be huge, and compiling a lot of applications is slow.

Modern frameworks like Drupal or Ruby on Rails use a central controller approach to web applications, and that will suite ISE Eiffel well: just a single application that will handle all requests. As it would be too slow to start that application for every request, the application will either need to do FastCGI or have a built-in web server.

In both cases we need to determine how to handle requests: handling a request at a time is unacceptable. Event-driven frameworks are probably unsuitable (and hard to work with). We could fork upon request, and that would probably have been the most desirable model before SCOOP. But forks also limit scalability, i.e. we might be able to handle only a few hundred requests per 2GB of memory. But with SCOOP we supposedly have an extremely friendly way of doing multi-threading, and a potential to scale to thousands of concurrent requests per server.

So that's the model I have chosen to implement my new web framework.

More details in the next post.