Talk:Eiffel Design Feast June-2011

Feel free to add suggestion here.

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.

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 13:42, 22 June 2011 (UTC))

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 19:32, 22 June 2011 (UTC))

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...