Team Eiffel

The Bay Area Friends of Eiffel have issued an open invitation to their gathering this evening, for people with an interest in the Eiffel programming language.

The meeting takes place at AXA Rosenberg in Orinda, on Wednesday, June 28, starting at 6:30. Directions to the offices of AXA Rosenberg are here: http://www.axarosenberg.com/axar-contact.htm/axar-location-orinda.htm

The meeting will be in building E, in the conference room near the lobby. As you approach building E from the parking lot, you'll see a large sliding glass door. This is the main entrance. If the main entrance is locked, you'll find a telephone in a box beside the door. You can dial extension 343 to get the attention of those in the meeting room.

There will be a surprise presentation followed by dinner, and Greg will tell his recently-refactored Eiffel joke "after imbibing".

In one of the comments, Roger mentioned How I explained REST to my wife. Worthwile read. It's worthwhile to quote this:

Wife: So this is what you and all the computer people are working on now? Deciding what the data should look like?

Ryan: Sadly, no. Instead, the large majority are busy writing layers of complex specifications for doing this stuff in a different way that isn't nearly as useful or eloquent. Nouns aren't universal and verbs aren't polymorphic. We're throwing out decades of real field usage and proven technique and starting over with something that looks a lot like other systems that have failed in the past. We're using HTTP but only because it helps us talk to our network and security people less. We're trading simplicity for flashy tools and wizards.

Wife: Why?

Ryan: I have no idea.

Sad isn't it? I realise that certain things I find simple, others might find very complex. But my goal in programming is to strife for simplicity and elegance. But that goal isn't shared, at least not in the meaning I attach to the word simple. The company that employs me has decided to go for the .NET route. And they will also use the word simple: VisualStudio makes creating web pages simple. Well, in one sense it does. Just like Delphi makes Rapid Prototyping Simple. The power of Delphi to create certain things really fast is amazing. And it works for a certain kind of simple applications. But there will come a point in your life that you've been fighting events and callbacks too much. Then the realisation will dawn that a lot of time you're fighting the tool. That a lot of time the ability to easily write some code behind a callback doesn't help maintenance, reuse, portability, abstraction and all these things.

VisualStudio is like that. It's a bit like Rapid Prototyping on the web. Yes, it's easy to create a grid that gets data from a database. You can scroll through it, and edit it. Cool. But that's hardly what a web application is about. Thinking about resources, about URLs, clean URLs, all the things that matter, are hard.

Three months ago, class INTEGER started to disappear from the SmartEiffel development version. You can still declare an entity to be of type INTEGER, but it's nothing more than an alias for INTEGER_32. In the future this may change - for example INTEGER could become an alias for INTEGER_64.

The xxx.to_integer and xxx.is_integer calls have also disappeared. You now need to use sized calls such as xxx.to_integer_32 or xxx.is_integer_16.

Class REAL has also disappeared, becoming an alias for REAL_64.

EiffelStudio is moving in the same direction. In a recent posting to the Es-devel mailing list, Emmanuel Stapf wrote:

STRING won't exist anymore, it will be replaced by STRING_8. Don't worry, the compiler will still accept STRING, because our new project configuration will let you decide what you want STRING to be. The same applies to the following classes and I'm also giving you their default meaning:

• STRING -> STRING_8
• INTEGER -> INTEGER_32
• NATURAL -> NATURAL_32
• REAL -> REAL_32
• DOUBLE -> REAL_64
• CHARACTER -> CHARACTER_8
• WIDE_CHARACTER -> CHARACTER_32
• INTEGER_REF -> INTEGER_32_REF
• REAL_REF -> REAL_32_REF
• DOUBLE_REF -> REAL_64_REF
• CHARACTER_REF -> CHARACTER_8_REF
• WIDE_CHARACTER_REF -> CHARACTER_32_REF

If you are happy with the default mapping, then you don't have to do anything, the upgrade will be completely transparent for the Eiffel compilation. Otherwise, you can simply override this mapping and define your own.

Emmanuel pointed out a few consequences of such a change at runtime: features 'generator' and 'generating_type' would now display STRING_8, INTEGER_32 etc; also affected would be the INTERNAL class, the CECIL call-in mechanism, and the STORABLE mechanism. Emmanuel writes:

The last one would break a lot of existing applications if nothing is done about it. Indeed when looking for STRING, nothing will be found and thus a retrieval error would be raised. To solve this, we are proposing to do the following: when we cannot find a class, we search a possible mapping in our predefined mapping (the one above). This lookup will be activated by a toggle which is on by default. For newly created storable, the toggle will be disabled upon retrieval (it means that we will change the version number of our independent store format, making new version non-retrievable by old systems).

Designing a REST based site consists of determining what the resources are for this site. And how to map them to URLs. It usually helps to actually start with URLs as the resources tend to follow from that. So the design of a web site based on REST consists of summing up the URLs and determining how many of the four verbs (GET, POST, PUT and DELETE) apply to them. And that might depend on the person doing the action, i.e. security.

Resources can also be found by listing the nouns in the requirements document of a customer. Perhaps that reminds people of a strategy advocated in the 90s when OO was all in vogue and used as a way to write a design that could be understood by these customers. We had to do that at the university: given a story about a system a customer wanted build, just extract the nouns. They were to become your classes. This was perhaps defensable as an approach for people who were totally clueless. And OOSC2 wasn't out yet.

These days we hopefully realise that such an approach is mistaken. OO is an implementation technique. Programmers use it to attain desirable program properties such as abstraction and code reuse. OO has little to do with a blueprint you would like to present to a customer. For example implementing Supplier and Customer as two separate classes is quite misguided. What happens when a Supplier also becomes a Customer?

Real world objects might map to objects used in software design, but it shouldn't be a goal in software design. Software has its own reality. Often the design improves if they don't match and if the programmer increases the abstraction level of his or her design.

This is different from resources I believe. Because resources are mapped to URLs and because URL guide customers and should be readable and understandable, resources are much closer to the reality of the customer and it is desirable to mimick that reality. It is logical for a user to go to /customers/ to see the list of customers and to go to /suppliers/ to see the list of suppliers. That underlying this is a single object called COMPANY and that a company can have the role customer or supplier or both, is an implementation technique.

So that's why EJAX is centered around resources. EJAX is an approach, an attempt to go as far as possible into a declarative way of building a web application. In deciding if URLs or resources should be the main focus, I decided on using resources. A resource can map to different URLs and that is just easier to do if resources are the things you describe and map them separately to URLs.

Here an example of the declaration of resources and the HTTP verbs that are applicable for this resource (this might depend on HTTP security):

<ejax-application>

  <resource name="suppliers">
    <url>/suppliers/</url>
    <get/>
    <put>
      <parameters>
        <parameter name="system_id">
          <data type="positiveInteger"/>
        </parameter>
        <parameter name="company_name">
          <data type="string">
            <param name="maxLength">256</param>
            <param name="whiteSpace">collapse</param>
          </data>
        </parameter>
      </parameters>
    </put>
  </resource>

  <resource name="customers/">
    <url>/customers/</url>
    <get/>
    <put>
      <parameters>
        ...
     </parameters>
    </put>
    <delete>
    </delete>
  </resource>

</ejax-application>

The parameters for a verb can be supplied in a variety of ways:

1. As part of the url, for example /customer/41 could pass 41 as the value for the parameter customer_id. The URL defined for this resource would be /customer/(customer_id).
   
2. As part of the query string, for example /customer?customer_id=41.
   
3. As a cookie.
   
4. In the body of the request if this is a POST or PUT request.

It does not really matter how the parameters are given and they can be supplied in any combination. All that matters is that they are combined into a single value space according to well-defined conflict resolution method. For example a query string parameter overrides a parameter passed in a cookie.

The definition of the parameters themselves is taken from Relax NG. Each parameter has a name and inside it follows the data tag, exactly as Relax NG defines it. The type is an XML Schema data type and the data type can have a number of parameters.

Based on this definition we can emit a CGI or Fast CGI Eiffel class that strictly validates if the verb is valid and if the passed parameters are valid.

Besides Eiffel, one of my favorite programming languages is Python. Python is an open-source, dynamically typed, object oriented interpreted programming language, which has become quite popular in the last years, and a significant community has formed around it.

As almost every community formed around a programming language, it has a set of design principles and way of solving development issues; this set of principles is directly related to the principles behind the language design and the facilities provided by the language. In the python community, a solution or piece of code conforming to these principles is said to be
"pythonic".

The Eiffel community is lucky to know the design principles supporting the language, thanks to the care that Dr. Meyer took in the "Object Oriented Software Construction" book to explain them and name them. Most Eiffel programmers can argue about the "eiffelishness" of some solution citing
named principles as "Open-Closed Principle", "Command/Query Separation", and several others. Other communities have not so clear notion of their guiding principles (for example, the Perl community has just a mantra "There is more than way to do it").

The Python community has no "official" list of principles like Eiffel has, but there is a list called "The Zen of Python" which is widely accepted as the list of "pythonic principles". It is even distributed with python, hidden like an easter-egg:

$ python
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

I wanted to introduce this list because a lot is shared in Eiffel, even when the languages have large differences. In some aspects I even believe that Eiffel is more pythonic than python itself. In later follow ups to this post I will take some of these items and look at them from an Eiffel perspective. There is a lot in common (so, I am not surprised that I like both languages a lot).

Why use Eiffel for developing web applications? Let's answer that question by looking at what happens if you use PHP5 for example. The PRADO framework has a page on error handling:

Errors occur in a PRADO application may be classified into three categories: those caused by PHP script parsing, those caused by wrong code (such as calling an undefined function, setting an unknown property), and those caused by improper use of the Web application by client users (such as attempting to access restricted pages). PRADO is unable to deal with the first category of errors because they cannot be caughted in PHP code. PRADO provides an exception hierarchy to deal with the second and third categories.

When you use Eiffel, you immediately get rid of two categories of error: your stuff is compiled, not parsed. And errors like undefined functions and setting unknown properties are caught by the programmer, not by the user. Using Eiffel makes it possible to guarantee certain errors cannot occur. That is what strict typing and compiling is all about. Errors are caught before the user seems them. Eiffel is about a better user experience.

The architectural philophy behind EJAX is to use the web as it was designed. It is therefore based upon REST. As Roy Fielding, the author of the HTTP specification writes in his dissertation:

The World Wide Web is arguably the world's largest distributed application. Understanding the key architectural principles underlying the Web can help explain its technical success and may lead to improvements in other distributed applications, particularly those that are amenable to the same or similar methods of interaction. REST contributes both the rationale behind the modern Web's software architecture and a significant lesson in how software engineering principles can be systematically applied in the design and evaluation of a real software system.

So if REST is what the web is meant to be, we should surely follow its core principles to work with the web instead of fighting it. Approaches like SOAP are perhaps useful to get stuff through a firewall, but they fight the architectural underpinnings of web instead of working with it.

REST stands for Representation State Transfer. It argues that the web is a collection of resources upon one operates with verbs. Resources are for example products or customers. There's an endless list of them. Resources are usually, but not necessarily, things. Resources can be accessed by one or more URLs.

The verbs are much more limited: there are only four. GET to retrieve a representation of a resource, POST to create a new resource, PUT to update a resource and DELETE to delete a resource.

To give an example, we could have a resource called customer and make it available through the following URLs:

• a GET on /customers/ returns a representation, for example an HTML table, of all customers.
• a POST to /customers/ creates a new customer.
  
• a GET on /customers/40 retrieves customer number 40.
  
• a POST to /customers/40 updates customer number 40.
  
• a DELETE on /customers/40 deletes customer number 40.
  

WikiPedia has a good article about REST. Also useful is Paul Prescod's article on common REST mistakes.

I finally managed, after much gnashing of teeth, to produce another batch of SmartEiffel 1.2r7 .msi's. SmartEiffel's system.se should now point to the install directory. The LCC compiler should now work, and the SAFE kernel library is included in the libaries release. This isn't an interesting library, but it's the first step to start to include ECLI. And of course the libraries .msi includes the new eposix 2.4.

The releases:

1. Just SmartEiffel 1.2r7.


2. SmartEiffel 1.2r7 + LCC.


3. SmartEiffel 1.2r7 + LCC + Gobo 3.4 + eposix 2.4.

Before announcing these releases do really work, I first want to hear some reports from people that the stuff actually works on their system.

In the previous posts I explained that the EJAX page formatter takes an existing HTML page and a collection of responses and emits that as the HTML page to the browser. There is another reason for this architecture and that it is now easy to implement load-balancing and improve responsiveness.

The reason is that we can select not to apply or generate a response when the page is requested, but defer that. For example we could insert an iframe with a URL to a reponse. The browser will request that iframe when the page has loaded and we can make the page (inter)active before waiting for that response. Or we could use XHR (XmlHttpRequest), or AJAX, to retrieve portions of the page in the background, asynchronously.

The responses can come from different servers as well of course. All this helps to achieve a page that appears faster: it is generated faster because less processing is done on the server, and it appears faster on a user's screen because it is smaller: less bytes to send over the network.

So the proper architecture gives us options at deployment time. Depending on if we're serving a local network or to browsers on a mobile phone, we can target what portions of the page to send now and what to send later.

"What about includes?" was one of the comments on my EJAX overview yesterday. Let's take a more detailed look at how an ordinary HTML page goes through the EJAX page formatter style sheet.

First of all, you don't need includes if what you can include can be put in the main HTML file. A company could have a main HTML template wich everything static included.

But secondly, you can put special instructions in the HTML file. The page formatter recognises these. One of them is an include directive: . So that takes care of the cases where you indeed want to include stuff.

But the purpose of this post was to explain how the replacement mechanism works. The page formatter takes an ajax response XML file and an HTML file. The ajax response file looks like this (it's actually exactly like OpenRico):

<ajax-response>
 <response id="my-first-part" type="element>
   <p>hello</p>
 </response>
 <response id="my-second-part" type="element>
   <p>world</p>
 </response>
</ajax-response>

Within the ajax-response container there can be multiple responses. When processing the HTML file, each element that has an id equal to an id found in a response with type element, gets replaced.

But the page formatter doesn't just simply copy the response, it just applies the response actually. As the default template in the page formatter just copies the node and next applies its child elements, the effect is copying.

But you can also override behaviour. For example the EJAX page formatter has (currently some) support for XForms. So the response, or the HTML file, can contain things like xforms:input or xforms:select1 and that is converted to HTML. The ultimate goal would be to have reasonably complete support XForms so dependencies and calculations wouldn't require so much custom JavaScript. But that requires the ability to load and manipulate XML and being able to do XPath in JavaScript.

And of course the page formatter recognises the head tag and inserts the script tags to load the required JavaScript files. And forms, and it inserts form validation handlers.

It's satisfying that my vapour ware already made it to the top 15 in Google. These guys are fast!

Let me discuss one of the design choices I've made. There are two ways to get at output a browser understands: the final HTML. One is to let an XSL style sheet generate it (or an Eiffel program, that's all the same), and the other is to take an existing HTML file and modify it before sending it to the browser.

The latter approach is superior for more general purpose toolkits. You can let a designer create the layout, and you only replace portions of the page that have to come from a database.

The RICO guys had a really simple, and therefore smart, way of doing that: if an HTML element has an id, you can replace it's contents with something else. That's the approach I'm using. You just put a div or span somewhere, give it an id. That's all the designer needs to do. The page formatter takes the HTML page and replaces the contents of an element with the contents found in another XML file. Simple, predictable, powerful.

I've just released xplain2sql, my utility to convert Xplain to a variety of SQL dialects. One of the features it has is to emit an XML description of the generated SQL. I use that a lot to generate Eiffel code, for example classes to call stored procedures using ECLI.

Cyril Adrian has started a new project, called "ESE" for "Enterprise SmartEiffel".

The aims of the project are to:

• provide Enterprise libraries to SmartEiffel (database, components, object brokering e.g. web services, and so on)
• use the latest SmartEiffel technologies: non-conforming inheritance and plugins to name a few
• be totally SmartEiffel oriented, i.e. no compliance with any other
  Eiffel vendor, no compliance to any "high level API" outside of
  SmartEiffel itself
• be a buffer between SmartEiffel's way of changing core libraries
  and real world code
• provide to the business world a very visible display of what SmartEiffel is capable of doing

The ESE project can be found at SourceForge.

Cyril invites others to participate, and says that he will be "a lot less strict than the SmartEiffel core team as to who wants to help".

Reichenbach Etienne noticed that ISE Eiffel crashed with a segmentation fault if he compared a STRING with a STRING_32:

create {STRING_32} string_1.make_from_string ("String 1")
create {STRING} string_2.make_from_string ("String 2")
if string_1 < string_2 then ...

Emmanuel Stapf replied:

This behavior is expected, it is called a CATCALL in Eiffel terminology. The good news is that in the ECMA specification those won't occur anymore, but this hasn't been implemented yet in our compiler.

Back in 1992, the reply would have been:

This behavior is expected, it is called a System Validity Error in Eiffel terminology. The good news is that in the ETL specification those won't occur anymore, but this hasn't been implemented yet in our compiler.

The ECMA solution appears to entail a runtime penalty, which we can accept more readily in 2006 than we could have in 1992. The loss of expressiveness caused by the 1992 ETL solution and the later "no polymorphic catcalls" solution probably made them both non-starters.

Hubert Cater advises that an updated demo is available for Strategic Command 2 Blitzkrieg, a turn based strategy game written entirely in ISE Eiffel with access to DirectX via the EiffelCOM wizard.

There is also a patch to address many of the bugs found in the initial release.

Prompted by a failure of a recent preliminary build of EiffelStudio 5.7 on Solaris Sparc (because it had only been tested on Solaris x86), Emmanuel Stapf asks whether anyone can provide access to machines suitable for compiling EiffelStudio on various platforms.

A script would upload the EiffelStudio PorterPackage to the given machine, run the build, and download the result (an ISO image and a .tgz file). The machine would need to be permanently accessible, although it would typically be used for two to four hours per week.

Platforms of interest include HP-UX, Digital Unix (alpha), Mac x86 and Mac PowerPC, but various releases of Solaris, OpenBSD, FreeBSD and Linux would also be useful.

Raphael Simon has summarized recent improvements to interoperability between EiffelStudio and other .NET languages. In particular, the mapping between Eiffel and .NET properties is now much tighter:

• Every Eiffel attribute generates a .NET property
• Every Eiffel query coupled with an assigner generates a .NET property
• It is possible to use the 'inspect' clause on a .NET enum
• It is possible to generate .NET constructors that will call Eiffel creation routines. Use the 'dotnet_constructors' indexing clause to list the name of the creation routines that should be called by constructors

In addition, EiffelStudio's .NET metadata consumer has a popup baloon which shows more information and whose content can be customized using an environment variable.

It's now also possible to inherit from an Eiffel class which itself inherits from a .NET class.

Here are May 2006's top search queries that landed at eiffelzone.com.

The usual excuses apply: limited sample size, only reflects successful searches, not all queries were seeking Eiffel content. You can also browse the full stats.

1. lua
2. webshort
3. gote
4. matisse
5. bison
6. ewg
7. goanna
8. hotbabe
9. por da lua
10. eiffel ide
11. black tree
12. eiffelzone
13. kniffel
14. serialization eiffel
15. mandolin
16. telnet
17. eiffel software
18. pipework
19. eiffel serialization
20. kermode

It's not surprising that SmartEiffel has lost much of its user base over the past few years.

After the release of version 1.1 everything went quiet for over a year. The SmartEiffel team promised that those who waited patiently would be rewarded with something fantastic.

When this fantastic thing arrived, the download was much bigger than SmartEiffel 1.1, and took much longer to compile our projects. And, most importantly, it broke virtually every existing library and tool. In response to the despair that this generated, Dominique Colnet suggested that we didn't need to worry about outside libraries anymore, because pretty much everything useful was now included with SmartEiffel.

By a herculean feat, Eric Bezault eventually got Gobo to work with SmartEiffel 2.1. As if to kick sand in his face, the SmartEiffel team then removed the case-insensitive option upon which Gobo depended. This was enough to drive Gobo and ePOSIX away from SmartEiffel 2.x. It didn't help that the SmartEiffel Public Relations spokesman wrote this:

I think it is better for you not to rely on Gobo. By using the library provided with SmartEiffel, you'll have less broken code in the future.

Knowing that Eric Bezault is a major actor of the definition of ECMA Eiffel, relying on Gobo means that you prefer ECMA Eiffel. So, if you go for Gobo, do not complain after that that Gobo is no longer supported by (Smart)Eiffel.

So, you have two possibilities: Gobo+ISE or SmartEiffel.

Trying Gobo+SmartEiffel is a bad mixture.

Have a good day,

PS: what is missing in our library ? As far as I know, you got more than Gobo.

So why would anyone use SmartEiffel 2.x for any non-academic purpose? Well, I'm using it for my Amber for Parrot project, and for me it's the best of the available options.

The show-stopper for me is licensing. I am hoping that Amber for Parrot can be included with the Parrot Virtual Machine. That requires my contributions to use a license compatible with both the GPL and Perl's Artistic License. Furthermore, the license must cover the Eiffel runtime too, because I distribute the C-package generated by the Eiffel compiler - and it includes runtime code.

The SmartEiffel team kindly modified the licensing for SmartEiffel 2.2 to make this possible (thanks!).

Also, in my opinion, the SmartEiffel team have done some great things (in addition to disasters such as the smiley operators and the loss of the case-insensitive option).

The "select" keyword is gone, together with the anomalies that it entailed. Anchored declarations have been cleaned up nicely. Expanded types have been reworked in a way that is a little less expressive but much safer.

And all this is being done in a way that simplifies the language. A nice achievement! I look forward to the publication of the paper that documents the new type system.

I'd much prefer that Bertrand Meyer and Dominique Colnet had seen eye-to-eye about the evolution of Eiffel. Given that they couldn't reach agreement, I think it has turned out as well as it could have under the circumstances, for both SmartEiffel and EiffelStudio.

SmartEiffel is dead. Long live SmartEiffel!

Franck Arnaud advises that Axa Rosenberg is seeking an Eiffel programmer for their London office. According to Franck, Axa Rosenberg "is one of the largest industrial users of Eiffel, and a very good one to work for".

Hmm, if they weren't looking for someone with an MS, I might even be applying myself...

Martin Schwenke, the previous maintainer of the Emacs Eiffel mode has allowed me to take over the maintenance of eiffel.el. But it has been quiet on this front for a while. So what has happened?

First of all the eiffel.el and its version history has been uploaded to SourceForge. There have been a couple of commits, each fixing a known issue.

But I've hit a brick wall with supporting a very minor case:

class TEST

inherit

  PARENT
    export {NONE} all end

After this the indentation didn't go back to the PARENT level, but stayed below export. Annoying. But to support this I decided I had to rewrite the current indentation support once again. And that didn't work properly, so I'm rewriting it again. It gets simpler every time :-)

Once this works well, and is confirmed by Colin Paul Adams, there will be a new release.

Long-time Eiffel iconoclast Llothar Scholz writes in comp.lang.eiffel:

Two months after the ISE deal it seems that the people who thought "Eiffel just needs a good open source compiler" are really wrong.

Instead of seeing more newbie questions this newsgroup is more silent then ever ... So is eiffel doomed or already buried?

Several people replied, pointing out that comp.lang.eiffel may no longer be the sexiest place in town to hang out at.

In the late 80's and early 90's, comp.lang.eiffel was just about the ONLY place for Eiffelists to hang out at. An early attempt at a CompuServe forum didn't make much headway. Bertrand Meyer was an active participant on comp.lang.eiffel, and indeed many aspects of the design of Eiffel (and ISE's implementation of it) were discussed and resolved on comp.lang.eiffel.

Now, there are plenty of other places to hang out. If we just consider the YahooGroups mailing lists, we can see some of them:

• NICE-Discuss (137 subscribers)
• Eiffel Software (ISE) (871 subscribers)
• ePOSIX (71 subscribers)
• Gobo Eiffel (126 subscribers)
• Visual Eiffel (184 subscribers)

There are other more specialized Eiffel-related groups at YahooGroups too, such as the Bay Area Friends of Eiffel list. Bear in mind also that, for most of these groups, you don't need to subscribe in order to read them on the web.

There are also a bunch of Eiffel-related mailing lists at sites like SourceForge. The EiffelStudio lists at ETH Zurich must have a load of subscribers, and there's also the SmartEiffel list at loria.fr.

So, although comp.lang.eiffel may be relatively quiet nowadays, that's nothing more than a reflection of the relative unpopularity of Usenet and the continued specialization of Eiffel.

Let me publicly claim here the name EJAX. Vaporware at its best! I suppose anyone who wants to combine some AJAX and Eiffel will come up with this name, and I did a while ago. But I doubt I will have anything to release, or at least something that's in a usable format. What I like to have, and what I'm working on, is a declarative framework for web applications. Not only suitable for new ones, but to extend or modify parts of existing ones.

I'm developing this framework as part of some web development work I'm doing for a certain website (and I could do it in Eiffel). The goal is to generate most of the code in order to achieve a very high level of productivity. Because that is what counts. Else your time would be too expensive for many clients to afford on smaller website. I rely heavily on xplain2sql to do the database side. The framework should be independent of implementation strategies, so if you're using an eposix CGI or Goanna servlet should be just an option.

I like small frameworks, and I've found the prototype and Rico frameworks very useful, so that's what I'm using. But ideally you want to be independent of these as well.

I just released eposix 2.4.1. It requires Gobo 3.4, Gobo CVS won't work: Some of the highlights:

• EPX_HTTP_SERVER supports persistent connections.


• EPX_MIME_PARSER now parses the email fields. Not every content that can be in such a field is supported, but I doubt those corner cases are relevant.


• On Windows the error messages should be more informative.

See also the complete list of changes in epposix .

Because Gobo in its CVS state has renamed a few methods eposix uses, I also decided to make a beta 2.5 release that is identical to 2.4.1, but compiles against Gobo CVS.

Emmanuel Stapf has announced a new binary interim release of EiffelStudio 5.7.

There's a list of changes, of which I found the following three to be the most interesting:

• Inlined externals are implemented (as per ECMA Eiffel)
• Project settings are now saved "per target", keyed on the UUID of the configuration file
• A new '-local' option to the command-line compiler lets you do batch compilations without messing up the sttings from your ongoing development work

Windows, Unix, Linux, FreeBSD, Solaris and IRIX downloads are available, and there's also a PorterPackage for those using other architectures.