Talk:Eiffel Design Feast June-2011 - Revision history

Jfiat: Talk:Eiffel Design Feast 2011 moved to Talk:Eiffel Design Feast June-2011

2012-04-03T10:05:35Z

Talk:Eiffel Design Feast 2011 moved to Talk:Eiffel Design Feast June-2011

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

2011-06-26T07:59:38Z

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

Marco Piccioni at 20:59, 24 June 2011

2011-06-24T20:59:19Z

Jfiat at 15:39, 23 June 2011

2011-06-23T15:39:25Z

Alexander Kogtenkov: Cosmetics

2011-06-23T10:58:59Z

Cosmetics

Alexander Kogtenkov: /* Library support for efficient processing */ Added one more item.

2011-06-23T10:52:54Z

‎Library support for efficient processing: Added one more item.

Jfiat at 09:07, 23 June 2011

2011-06-23T09:07:15Z

Jfiat at 08:57, 23 June 2011

2011-06-23T08:57:00Z

Alexander Kogtenkov: Adde a section on goals of the future development

2011-06-22T19:32:44Z

Adde a section on goals of the future development

Alexander Kogtenkov: /* Library support for efficient processing */ Added an example for separate streams.

2011-06-22T13:46:24Z

‎Library support for efficient processing: Added an example for separate streams.

@@ Line 38: / Line 38: @@
 * 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.
@@ Line 43: / Line 44: @@
 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 <small><small>''([[User:Alexander Kogtenkov|Alexander Kogtenkov]])''</small></small> ==

← Older revision		Revision as of 20:59, 24 June 2011
Line 1:		Line 1:
	Feel free to add suggestion here.		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 ([http://mews.origo.ethz.ch 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:
		+
		+	[http://www.informatics-europe.org/cgi-bin/informatics_events.cgi?event&cmd=list 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 ''([[User:Jfiat\|Jocelyn]] 12:56, 22 June 2011 (UTC))'' ==		== Porting existing solution to common web solution platform ''([[User:Jfiat\|Jocelyn]] 12:56, 22 June 2011 (UTC))'' ==

← Older revision		Revision as of 15:39, 23 June 2011
Line 105:		Line 105:
	== Compression ==		== Compression ==
	Same question ... we might either implement an Eiffel solution, or wrap existing libraries...		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

@@ Line 13: / Line 13: @@
-== Library support for efficient processing ''([[User:Alexander Kogtenkov|Alexander Kogtenkov]] 13:42, 22 June 2011 (UTC))'' ==
+== Library support for efficient processing <small><small>''([[User:Alexander Kogtenkov|Alexander Kogtenkov]])''</small></small> ==
 '''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.
@@ Line 75: / Line 75: @@
 |}
-== Work directions ''([[User:Alexander Kogtenkov|Alexander Kogtenkov]] 19:32, 22 June 2011 (UTC))'' ==
+== Work directions <small><small>''([[User:Alexander Kogtenkov|Alexander Kogtenkov]])''</small></small> ==
 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

@@ Line 17: / Line 17: @@
 '''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. Finally, 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.
+'''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.
-'''Explanation.''' Different contexts that may benefit from adding some new features to the core classes are listed in the table below.
+'''Examples.''' Different contexts that may benefit from adding some new features to the core classes are listed in the table below.
 {| class="wikitable"
 |-
@@ Line 55: / Line 55: @@
 out_to (s: separate STREAM)
     do ... end</e>
 |-
 |}

← Older revision	Revision as of 10:05, 3 April 2012
(No difference)

← Older revision		Revision as of 09:07, 23 June 2011
Line 69:		Line 69:
	* etc.		* 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.		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 [http://www.openssl.org/ openSSL] ?
		+	* Wrapping [http://www.gnu.org/software/gnutls/ 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...

@@ Line 1: / Line 1: @@
 Feel free to add suggestion here.
---[[User:Jfiat|Jocelyn]] 12:56, 22 June 2011 (UTC)
+== Porting existing solution to common web solution platform ''([[User:Jfiat|Jocelyn]] 12:56, 22 June 2011 (UTC))'' ==
-What about porting Goanna to EiffelWebReloaded (and at the same time, update it to be support standard syntax, and 6.8 compiler). 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.
+Existing solutions:
 == Library support for efficient processing ''([[User:Alexander Kogtenkov|Alexander Kogtenkov]] 13:42, 22 June 2011 (UTC))'' ==

← Older revision		Revision as of 19:32, 22 June 2011
Line 48:		Line 48:
	\|-		\|-
	\|}		\|}
		+
		+	== Work directions ''([[User:Alexander Kogtenkov\|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.

@@ Line 37: / Line 37: @@
 | Support strings/streams from different processors.
 | <e>append_string (s: STRING)
     do ... end</e>
 | <e>append_string (s: separate STRING)
     do ... end</e>
 |-
 |}