From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA14992; Tue, 3 Apr 2001 09:11:09 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA14936 for caml-list@pauillac.inria.fr; Tue, 3 Apr 2001 09:11:08 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA06044 for ; Mon, 2 Apr 2001 23:21:15 +0200 (MET DST) Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f32LLED19995 for ; Mon, 2 Apr 2001 23:21:15 +0200 (MET DST) Received: from [195.20.224.204] (helo=mrvdom00.schlund.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14kBlC-0004qs-00; Mon, 2 Apr 2001 23:21:14 +0200 Received: from drms-3e3653a1.pool.mediaways.net ([62.54.83.161] helo=ice.gerd-stolpmann.de) by mrvdom00.schlund.de with esmtp (Exim 2.12 #2) id 14kBl3-0004A9-00; Mon, 2 Apr 2001 23:21:06 +0200 Received: from localhost (localhost [[UNIX: localhost]]) by ice.gerd-stolpmann.de (8.9.3/8.9.3) id XAA23886; Mon, 2 Apr 2001 23:13:16 +0200 From: Gerd Stolpmann Reply-To: gerd@gerd-stolpmann.de Organization: privat To: "Mattias Waldau" , Subject: Re: [Caml-list] Using HTML as a standard GUI for Ocaml Date: Mon, 2 Apr 2001 21:16:11 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01040223131601.00489@ice> Content-Transfer-Encoding: 8bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, 31 Mar 2001, Mattias Waldau wrote: >- Is the idea below good or bad? >- I am looking for ideas how to implement the idea below. >- Making some kind of JSP/ASP-package for Ocaml could be a solution, >but code likes that gets very messy. >- What has been done? Unpublished code? >- Alternatives? I'm doing a lot of professional development for web applications. These are typically intranet applications, and many companies like such apps because there is no need of client installations (which are very expensive to maintain). So I think I can answer these questions. >Using HTML for GUIs >=================== > >Today there exists two flavors of gui for Ocaml based on Tcl or GTK. >Tcl is portable, and GTK is becoming portable. > >What about using HTML-interfaces >instead of standard GUIs like Tcl and GTK? > >The architecture is >that you start some kind of HTTP-based server and than you >start the browser and go to a local adress like >http://localhost:8989/start.html. > >The advantages are >- Portable This is only true for HTML 3.2 because all current browsers support this standard. HTML 4.0 + Ecmascript + DOM + CSS could become portable in the future, but this is not yet the case. In the moment, I am developing an application which must run under both Netscape 4.x and IE 5.0 browsers, and this is a nightmare if you begin to use features beyond HTML 3.2. The point is that the customer/user already has installed some type(s) of browsers on the clients, and that the server must cope with that. Otherwise one of the main goals (reduce client costs) of such installations cannot be achieved. >- Much nicer looking GUI's, it is easier to add pictures, fonts etc > to a HTML-gui, than to a Tcl/GTK-based Agreed. However, nice GUIs are also possible with Tk or GTK, and I think there are also HTML renderers for these toolkits. >- Many GUI-operations are easier to do in HTML than in a standard > GUI-tool, for example HTML-tables are easier to create the > listboxes with columns. Only "display operations" are easier. Input operations are very restricted in HTML. On the other hand, it is much more complicated to program the dialogue control for web applications, because you have the strict request/response scheme of the underlying protocol. >- Easy to create server-based solutions out of client-applications. > Only need to handle state in a general and scalable way. Yes, and this is not simple, even with toolkit support (see below). >- Smaller executables, for example including GTK statically into > Unison increases the size from 700Kb to 2400Kb on Windows. This does not count, because libraries can be shared between executables. So if you have ten different executables for GTK, the GTK library is only loaded _once_. Statistically, GTK has shrunken to the size of 1700K/10 = 170K. This is hard to beat. Let us compare that with the resource usage of web applications. There are two widely used architectures: - CGI: Every request creates a new process. This has the _big_big_big_ advantage of unbeaten stability because requests cannot interfer. However, many initializations of the application have to be done for every request, e.g. opening database connections. Because of this, CGI applications cause a high server load (Note: For web services, one CGI request per second is already regarded as high load). - Application servers: The same process can accept multiple requests, and performs them either serially or in a multi-threaded way. This reduces the load (usually) dramatically, but for this architecture the app must be coded much more carefully because the requests share implicitly state. (E.g. you must close all files otherwise you get out of file descriptors after a while.) I recently developed a mixture of both: An application server that forks for every request; it was quite successful. You see (as a rule of thumb): Either you have a simple architecture and high loads, or a complex architecture and low loads. Perhaps it is possible to find a simpler solution for one-user applications (i.e. every user has its own server); this could be comparable to the requirements of "traditional" toolkits. But then the implicit multi-user accessibility of web applications goes away. >- Easier to integrate with other applikations, since two > applications can merged on the HTML-page This is one of the big advantages of HTML-based apps. >The disadvantages are >- slower >- difficult to set focus correctly if the whole page is updated > after each input (bugs i IE). This can be solved by being > XML-based and talk XML from the browser to the server (which > only works on IE>=5 and Netscape 6). Don't know. I never wanted to set the focus for web apps. >- browser incompabilities. (for example HTC in IE makes event > very easy to handle, but incompatible with active sheet on Netscape, > which is buggy) Yes, a nightmare. By the way, I have a web toolkit for Caml. It allows the programmer to describe the application in an XML document, and to add callbacks to the interesting events. The toolkit solves the details of keeping the state of the application instance, and provides a way to form HTML pages from fragments. I'm using it for many of my professional developments. However, it has one major drawback: My boss owns it, and not me. There is a realistic chance to make it available under the GPL (yes, GPL, such that nobody else can use it for commercial projects). The application uses persistent objects that "survive" between request/response cycles. In an XML document these objects can be declared, e.g. ... There is always one main object which typically reflects the current dialogue state of the session. (Instance) variables contain dynamically created contents of a page, or serve as target for input elements. What is sent to the browser is a view of the main object computed by expanding a mixture of HTML elements and toolkit elements (these have the prefix ui:). E.g.:

This is a sample page!

The value of variable x: . Please enter variable y: When an event happens (button is pressed, or a hyperlink) the toolkit calls back a user-supplied function or method, and the system can react on the event. Complex HTML pages can be formed by instantiating templates. A template is an HTML fragment containing free identifiers (using dollar notation): - Abstraction: This is $p1 and that is $p2. - Application: one parameter another parameter Note that this is not a lambda calculus because abstractions must be done at top level. The resulting application normally separates strictly HTML parts (the layout) and the programmed code (for the callbacks). The toolkit enforces a clear concept for the application getting better maintainability. If anybody is interested in such a toolkit, I can package a version 0.0 tarball with very incomplete documentation (and perhaps only bytecode and no sources), and only a few samples one can learn from. Gerd -- ---------------------------------------------------------------------------- Gerd Stolpmann Telefon: +49 6151 997705 (privat) Viktoriastr. 100 64293 Darmstadt EMail: gerd@gerd-stolpmann.de Germany ---------------------------------------------------------------------------- ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr