Friday, July 22, 2011
The Eiffel Web Server Gateway Interface
Jocelyn Fiat alerted me to the The Eiffel Web Server Gateway Interface framework. This seems to be a useful proposal to write a standard framework for Eiffel apps.
Would like to see some changes, particularly providing less implementation - unless eposix gets adapted :-) - but building upon that would mean it would be much easier to plug in other Eiffel components which know nothing about my FastCGI server implementation.
Would like to see some changes, particularly providing less implementation - unless eposix gets adapted :-) - but building upon that would mean it would be much easier to plug in other Eiffel components which know nothing about my FastCGI server implementation.
Eiffel framework for web applications
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.
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.
Thursday, July 14, 2011
New Eiffel Technology Community
Thomas Beale posted the results of the Eiffel Technology workshop, an attempt to revive interest in Eiffel.
Unfortunately I couldn't attend, but my initial question to the mailing list captured my reservations: what's the itch?
People having as a goal to do X, instead of solving an actual problem, won't have the motivation and the time to continue. So such projects won't achieve much. What it could achieve would be to create a set "how do I X in Eiffel?" I.e. how do I open a file in Eiffel series. In a wiki style, or perhaps better stackoverflow style these days. Or maybe use stackoverflow, they have the infrastructure. Just answer your own question!
I myself have largely given up on the question to promote Eiffel for the sake of Eiffel. I find it uninteresting. I'm doing a lot of Eiffel, there is simply no competitive, current compiled language which covers as many platforms as Eiffel. So I use it.
I'll be returning to these pages soon to start my thoughts on a new Eiffel webplatform. I've worked and done a lot with "ejax", but I'm using only ISE Eiffel and gec now, and secondly there's SCOOP so time to do something different!
Unfortunately I couldn't attend, but my initial question to the mailing list captured my reservations: what's the itch?
People having as a goal to do X, instead of solving an actual problem, won't have the motivation and the time to continue. So such projects won't achieve much. What it could achieve would be to create a set "how do I X in Eiffel?" I.e. how do I open a file in Eiffel series. In a wiki style, or perhaps better stackoverflow style these days. Or maybe use stackoverflow, they have the infrastructure. Just answer your own question!
I myself have largely given up on the question to promote Eiffel for the sake of Eiffel. I find it uninteresting. I'm doing a lot of Eiffel, there is simply no competitive, current compiled language which covers as many platforms as Eiffel. So I use it.
I'll be returning to these pages soon to start my thoughts on a new Eiffel webplatform. I've worked and done a lot with "ejax", but I'm using only ISE Eiffel and gec now, and secondly there's SCOOP so time to do something different!