Revision as of 14:32, 4 December 2006

Warning: Warning: Article in development, please come back when the warning will be removed

This page address the rationale behind the new ECF configuration format, and clarify what needs got covered by the new system.

Why the change?

As part of the EiffelStudio 5.7 project plan (made in 2005), we finally decided to improve the way one build a project using EiffelStudio. Most of the ideas introduced in 5.7 have originated from discussions we had over the past 6 years with both employees of Eiffel Software and users of EiffelStudio. We actually decided changing this a while ago, but lack of time and various constraints prevented us from doing it until 5.7.

Here are the major points raised by the above discussions:

• The Project Settings dialog of EiffelStudio 5.6 (and earlier) was not complete, that is to say not all the Lace constructs could be reached from the UI.
• Lack of clear documentation on the most complex aspect of the Lace specification: mostly class renaming, but also recent additions to Lace for .NET projects.
• It was hard to have one Ace file for building portable system, usually one needs to have at least three Ace files: one for Windows, one for .NET on Windows and one for UNIX. With the possible addition of Mono on UNIX, it could put this number up to four.
• When you had C code that depended on the Eiffel Software runtime, you needed again two additional Ace files: one for workbench mode and one for finalized mode.
• When you had a library that could be compiled in mono- or multithreaded mode, again you would need two Ace files: one for monothreaded and the other one for multithreaded.
• One could not have both debug and release build of the same project in the same Ace file, again two Ace files are required.
• The class renaming mechanism was completely not understood and actually difficult to use without asking Eiffel Software how it worked.
• The addition of .NET components increased the class name clashing dramatically requiring a robust class name clash resolution mechanism.
• Recursive clusters were actually actually transformed into actual clusters, making it sometime hard to apply some of the Lace construct specification involving clusters, since cluster names had to be guessed by the end-user.
• Override clusters were simply a hack over normal clusters preventing users from seeing which classes they were actually overriding.
• Support for ECMA type mapping needed to make INTEGER be INTEGER_32, NATURAL be NATURAL_32, etc...
• Even if Lace was a public format (specified in ETL2), the Eiffel Software's implementation was quite different and there was no library available to parse it.

Why the syntax change?

Because we wanted to make most modification through the UI or through the configuration library, we could have used an object binary format, but we did not chose this approach since it makes configuration versioning in CMS tool completely useless since one cannot visually see the differences.

So we were left with:

1. modifying lace
2. adopting a new syntax
3. using the quite common XML syntax

At the end, we chose XML for the following reasons:

• We wanted new Eiffel users to easily create their own configuration. XML is very good at that since XML aware text editor are able to provide code completion when we provide a schema, which we do. With Lace, not being self-describing, it is harder for someone completely new to Eiffel to feel what possibilities are offered to him.
• Anyone could parse XML no need for a special parser
• The node ordering in XML matches nicely with the layout of an Eiffel system, that is to say, you have libraries, within libraries, you have clusters, within clusters you have either classes or clusters.
• Schema evolution: with a XSL transform, it is easy to automate conversion from successive revisions of the XML file without building complex tool.
• There were some semantics changes we added in the new configuration approach that would have required an upgrade from the old Lace format to the new one. So no matter the chosen syntax, a migration was necessary. And because XML offered more than Lace for processing, this was one more reason to choose XML.
• XML was already used by other tools addressing some of the shortcomings of Lace.