Talk:Eiffel Design Feast June-2011

Feel free to add suggestion here.

My 2 cents on Eiffel for the Web (Marco Piccioni)

I actually like the inspiring principle of the EiffelWeb library: generating HTML code dynamically and in the end having a binary file (.cgi) executable on any web server. It is simple, and works even reasonably fast in my experience. This sounds good as a starting point, so I wouldn’t dismiss it lightly. Of course there are a lot of features that are missing, so one of the projects that I supervised 4 years ago (mews) managed to improve on the basic EiffelWeb providing:

• Predefined layouts (2 columns, 3 columns)
• Output in standard strict html ([www.w3.org]) and css
• Support for adding lists and tables to content areas
• Web app configuration file
• Reflection-based request dispatching and handling mechanism
• HTML generation based on templates
• Session support (using cookies and URL rewriting)
• Support for user management and authentication
• Support for form validation

An application using the framework, still in very good shape after 4 years:

CSEL

That said, more can be done, like:

• Using FastCGI
• Providing an interactive graphical web mode in EiffelStudio supporting the design of complex web apps
• Applying all the support for efficient string processing that Alexander mentioned below
• Providing an easy way to debug FastCGI apps using EiffelStudio (I know it is possible using a console, activating a trace and then checking a text file, but it would be nice to actually use the available debugger)

This I think should be the baseline.

In general, we should go for the simplest solution that delivers the most benefits and provides the least effort from the browsers (i.e., it should work with all the browsers without requiring plugin downloads). For example it is good to do some simple client-side processing using javascript, because now it is mostly standard and every browser understands it. For the graphics, we don’t need to worry. A good technology in the end, that is standard and open source, and that looks like Flash but it is not that bad for browsers and developers.

To finish, I don’t think that a solution involving Eiffel used as a scripting language, therefore mixing Eiffel, HTML and Javascript in the same page is any good. Two reasons:

• There are web developers (good with html, javascript and css), and application developers (good at programming). It is more productive to minimize the possibility of technical conflict by keeping their jobs separate. JSP have failed with this respect.
• I don’t think that the Eiffel compiler can win a speed race with the Java compiler (not yet?). I doubt that mimicking the same jsp approach of compilation on the fly we will ever achieve decent performance. The compiler cannot be that good and that fast at the same time (can it?), and we are adding layers of indirection without a real reason

Porting existing solution to common web solution platform (Jocelyn 12:56, 22 June 2011 (UTC))

Existing solutions:

• EiffelWeb: kind of too simple (or even obsolete)
• Goanna: not actively maintained (apart for Neal's fork ... available?)
• Xebra: attractive solution, but not very flexible, and require to write and maintain specific web server module/handler ... And people like or not the web application management/auto-recompilation.
• MEWS

In any case, each solution has valuable code, and existing projects using them. I think it would make sense to port the "library" part of them to new web solution framework EiffelWebReloaded, and then actively maintain them.

Actually Goanna would benefit from extracting the connector implementation from the main libraries (servlet, ...), and then it could fit nicely with EiffelWebReloaded, where you can choose which "connector" you want to use (and compile). The Goanna connectors (Fast_CGI, CGI, Standalone), could then be redesigned to be valid EiffelWebReloaded connectors. Same for Xebra, where we could reuse some of the web library.

Library support for efficient processing (Alexander Kogtenkov)

Background. Web technologies are using streams and text messages for interaction between participans be they computers, devices or humans. Usually this involves reading incoming text information, i.e. parsing, and writing outbound data, i.e. generation. Because of the text nature both extensively work with strings that are represented in one way or another.

Idea. Current interface of string classes assumes all the strings are manipulated like objects. There is no way to pass a half of the string from the reader or to the writer. The interface can be enhanced to manipulate substrings instead of the complete strings. Additional string objects can also be avoided if a writer is passed directly, so that one can write directly to the output rather than create a temporary object that will be processed somewhere else. String cloning can be avoided if the features accept separate objects. Because separate arguments are locked during the call it should be safe to retrieve any required informtion directly from the separate string/stream without any additional overhead. If the processing cannot be done on-the-fly and still requires storing the character data, it can benefit from using a central highly-optimized dictionary that would avoid creating and keeping string objects as well.

Examples. Different contexts that may benefit from adding some new features to the core classes are listed in the table below.

t := s.substring (i, j)
buffer.append_string (t)

buffer.append_substring (s, i, j)

out: STRING
   do ... end

out_to (stream: STREAM)
   do ... end

append_string (s: STRING)
   do ... end
 
out_to (s: STREAM)
   do ... end

append_string (s: separate STRING)
   do ... end
 
out_to (s: separate STREAM)
   do ... end

put (s: STRING)
   do ... end
 
item (index: INTEGER): STRING
   do ... end

put (s: STRING; first, last: INTEGER)
      -- Put `s.substring (first, last)'.
   do ... end
 
last_index: NATURAL -- Set by `put'
 
less (i, j: like last_index; c: COMPARATOR): BOOLEAN
      -- Is item of index `i' less than item of index `j'?

Work directions (Alexander Kogtenkov)

One major point of the work is to define clean goals to be achieved. Depending on them it would be easier to figure out and organize means. The goals may be quite different and I think it makes sense to position the final result with a one simple goal like

• the fastest web server
• the most homogeneous web environment
• the most portable web solution
• the simplest processing scheme
• the most straightforward way to run desktop application in a web environment and vice versa
• the easiest language binding for parallel execution of web application
• etc.

As soon as the goal is known, it can be put as a flagship for driving the community as well as for promoting Eiffel products as self-contained and mature artifacts that are important to be aware of.

TLS and SSL / security layer

Should we handle the TLS in the "server" web framework? I guess no, since by using FCGI (for instance) we benefit from the related web server support for such security layers. Now, for the "client" part, this might be required. Indeed we want our web server application to be able to consume other web services.

• Wrapping openSSL ?
• Wrapping gnutls ?
• using Eiffel cURL for the client side?

Encryption

We also need a solid portable framework for encryption. The various solutions so far (that I know)

• Wrapping openSSL
• Wrapping gnutls
• eel and eapml written by Colin Lemahieu (see https://github.com/Eiffel-World/eel and https://github.com/Eiffel-World/eapml). Note that those 2 projects are not maintained anymore, but we could re-activate them by including them into a community central library , or maybe into EiffelSoftware libraries.
• maybe eposix also provides such encryption

Compression

Same question ... we might either implement an Eiffel solution, or wrap existing libraries...

P2P facilities

It would be nice to provide an easy way to establish p2p connection