Team Eiffel

Some lower level details: obviously the controller listens on a socket, as soon as a connection is received, it handles this to a separate thread.

The separate thread should handle everything else, which means reading environment/get/post/cookie variables, merging them, and handling the actual request. It's a bit unclear if The Eiffel Web Server Gateway Interface covers this properly. The spec appears to say yes, some of the code I've seen says no, but this can be easily fixed.

Frameworks like this often provide url to handler mapping, but as I'm targeting a REST based framework, this works somewhat differently, and therefore I'll discuss possibilities and options in a later post.

I wouldn't need authentication as the web server should handle this. Else resources not controlled by the Eiffel app (files) cannot be protected without hard-work.

Authorisation is necessary, and often complex. I'll probably like to have some configuration mechanism, but it would be nice to have a central place of configuration. So could have a reusable authorisation class that takes the name of the user, the verb (GET/PUT), and the variables, and returns TRUE/FALSE and some error text. Might want to have the ability to do an override at the lowest level (resource) as well.

More on resources in the next post.

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.

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.

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!

Compiling with ISE Eiffel is noticeably faster with my quadcore laptop. ISE really uses all cores, very nice. It might be that with 8 cores I hardly will speak of compile time at all.

"A Direct Path to Dependable Software" is the title of a recent article in the CACM. It piques the interest, but otherwise has few details on how the approach would work. But an interesting quote:

As the required level of confidence rises, though, testing soon becomes prohibitively expensive, and the use of more sophisticated methods is likely to be more economical. Invariants may be harder to write than test cases, but a single invariant defines an infinite number of test cases, so a decision to write one (and use a tool that checks all the cases it defines) will pay off very soon.

Interesting thread on Eiffel Software mailing list. Basically the difference between C and Eiffel code is negligible when enabling the right optimisations:

Now I have found out what makes the difference. If I pass the array t be
sorted as an argument of the sort function instead of using an
attribute, I get a significant speed up of EiffelStudio.

  ES finalized(+inline-void+arg):  8.403 sec
  C/C++ with g++ -O3:              8.133 sec

The difference is marginal and no longer significant.

CDD EiffelStudio has matured quite a lot recently. Quite a few bugs have been fixed and usability issues addressed. Some more will be addressed shortly.

The CDD website is new and improved. Featuring more documentation and better installation instructions. Visit it at http://dev.eiffel.com/CddBranch

In particular there is a new video that demonstrates the automatic extraction of test cases: http://se.ethz.ch/people/leitner/cdd/video/



Andreas

We Eiffel programmers often take a lot for granted, things that other languages just struggle with:

Are you ever sick of seeing Object get printed out when you try to output a variable to your console.

We Eiffel programmers just say:

  object.out

It's that easy.

The CDD extension for EiffelStudio is an ETH Zurich project which adds support for unit testing to EiffelStudio 6.1. The current status is "beta 2", and it's released for Linux and Windows. Features include:

• visualization of test cases and their outcomes
• one button creation of manual test cases
• limiting of visible test cases using predefined filters and custom tags
• test case management through tags

Two further features are particularly interesting. Testing can be configured to occur in the background, and is described as "undisruptive to the developer". If an unexpected exception is thrown, a new test case is automatically created to reproduce the exception. Features like these can make the difference between a testing system that is useful as opposed to one that is merely usable.