Re: [Caml-list] Using HTML as a standard GUI for Ocaml

[Gerd Stolpmann <gerd@gerd-stolpmann.de>]

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.

<ui:object name="whatever">
  <ui:variable name="x" type="string"/>
  <ui:variable name="y" type="enumerated"/>
  ...
</ui:object>

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

<ui:page>
  <html>
    <body>
      <h1>This is a sample page!</h1>
      The value of variable x: <ui:dynamic variable="x"/>.  
        <!-- ui:dynamic: insert dynamically generated contents -->
      Please enter variable y: 
      <ui:form>
        <ui:text variable="y"/>        <!-- ui:text: make a text input box -->
        <ui:button name="b" label="OK"/>
      </ui:form>
    </body>
  </html>
</ui:page>

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:

<ui:template name="t">
  <ui:expectparam name="p1"/>
  <ui:expectparam name="p2"/>
  This is <b>$p1</b> and that is <i>$p2</i>.
</ui:template>

- Application:

<ui:use template="t">
  <ui:param name="p1">one parameter</ui:param>
  <ui:param name="p2">another parameter</ui:param>
</ui:use>

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