Tuesday, August 02, 2011
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.
Friday, July 22, 2011
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.
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
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!
Wednesday, April 28, 2010
Tuesday, May 26, 2009
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.
Monday, February 23, 2009
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 secC/C++ with g++ -O3: 8.133 sec
The difference is marginal and no longer significant.
Wednesday, March 19, 2008
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/
Monday, February 18, 2008
We Eiffel programmers just say:
Are you ever sick of seeing Object get printed out when you try to output a variable to your console.
object.outIt's that easy.
Friday, February 08, 2008
- 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