* Re: [Caml-list] Using HTML as a standard GUI for Ocaml
2001-03-31 9:31 ` [Caml-list] Using HTML as a standard GUI for Ocaml Mattias Waldau
@ 2001-04-01 12:52 ` Fergus Henderson
2001-04-01 20:11 ` Sven LUTHER
2001-04-02 19:16 ` Gerd Stolpmann
2 siblings, 0 replies; 13+ messages in thread
From: Fergus Henderson @ 2001-04-01 12:52 UTC (permalink / raw)
To: Mattias Waldau; +Cc: caml-list, zs, conway
On 31-Mar-2001, Mattias Waldau <mattias.waldau@abc.se> wrote:
> What about using HTML-interfaces
> instead of standard GUIs like Tcl and GTK?
...
> - What has been done? Unpublished code?
Zoltan Somogyi and Thomas Conway, who have been implementing a new
profiler for Mercury, have been using this technique. The code is not
officially released, and at this point I suspect it is very much a
prototype, and probably not well documented, but it is available from
the Mercury CVS repository (on the `deep2' branch; the code for the CGI
interface is in the `deep' directory). I saw a public demo that Tom
gave here at the University of Melbourne about a month ago.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
-------------------
To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Caml-list] Using HTML as a standard GUI for Ocaml
2001-03-31 9:31 ` [Caml-list] Using HTML as a standard GUI for Ocaml Mattias Waldau
2001-04-01 12:52 ` Fergus Henderson
@ 2001-04-01 20:11 ` Sven LUTHER
2001-04-01 20:35 ` Bruce Hoult
2001-04-02 19:16 ` Gerd Stolpmann
2 siblings, 1 reply; 13+ messages in thread
From: Sven LUTHER @ 2001-04-01 20:11 UTC (permalink / raw)
To: Mattias Waldau; +Cc: caml-list
On Sat, Mar 31, 2001 at 11:31:43AM +0200, 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?
>
> Using HTML for GUIs
> ===================
can be a good idea, depending on your use.
>
> Today there exists two flavors of gui for Ocaml based on Tcl or GTK.
> Tcl is portable, and GTK is becoming portable.
Gtk is portable, it works at least on X, windows, the linux framebuffer device
(soon) and possibly some others.
> What about using HTML-interfaces
> instead of standard GUIs like Tcl and GTK?
Well, i think this may be a good idea (sun is doing this) if you need to run
your code remotely and for system configuration and administration.
But, ...
Most web browser are huge beast, running slowly and ressource hungry. Also i
think you can do less things with html than you can do with modern toolkits.
Also there is the question of bandwith.
> 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.
Sun is doing this for their system/wbe server administration, but then i guess
everyone using this has fast web connection and quick boxes wiht loads of
memory
> The advantages are
> - Portable
Sure, ...
But i think you don't envision to run it on a text based browser like lynx ?
> - Much nicer looking GUI's, it is easier to add pictures, fonts etc
> to a HTML-gui, than to a Tcl/GTK-based
Erm, ...
i don't think much people will be of the same opinion as you.
It may be easier for simple tasks, but there is much less things you can do
with HTML.
Also i hope you don't try to do OpenGL stuff and other such, i don't think it
will work.
> - 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.
But you have less control wit them, as well as one the callbacks you can add
to them. Also i am not html specialist but from what i know, the event loop
handling is really slow on a browser + server thing than what you can do with
even the slow tcl/tk toolkit.
> - Easy to create server-based solutions out of client-applications.
> Only need to handle state in a general and scalable way.
This has nothing to do with GUIs, ...
> - Smaller executables, for example including GTK statically into
> Unison increases the size from 700Kb to 2400Kb on Windows.
But you need the 20Mb + of mozilla/whatever installed.
> - Easier to integrate with other applikations, since two
> applications can merged on the HTML-page
mmm, ...
i don't know about this, but i think you will launch a cgi to generate the
html page. if you have 2 pages, you would need to launch 2 cgis and merge
them, or have one of them call 2 other and do the merging.
I think it trully depends on what you want to do. Please provide a more
detailed context, and we could discuss it in more details.
> The disadvantages are
> - slower
much slower, and ressource hungry, yes ...
> - difficult to set focus correctly if the whole page is updated
> after each input (bugs i IE). This can be solved by being
And naturally, don't forget that IE is not the only browser around.
> XML-based and talk XML from the browser to the server (which
> only works on IE>=5 and Netscape 6).
Sure, and XML is the solution to all your problems ... :)))
I am not that convinced, but then i am no XML expert.
> - browser incompabilities. (for example HTC in IE makes event
> very easy to handle, but incompatible with active sheet on Netscape,
> which is buggy)
Just use Standard html and forget about all the private extensions of the ones
and the others.
All in all, i think using html as guis is a solution only for the most
specialized of case, where having it running remotely is a requirement, like
in the sun case, but mostly it is simply to cumbersome and ugly to be of any
help for more advanced GUIs. I would not do it.
That said, in the ocaml oreilly book, you will find a chapter on how to write
a web server in ocaml, and some stuff that could lead to some of the things
you may want to do, please read it.
Friendly,
Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Caml-list] Using HTML as a standard GUI for Ocaml
2001-04-01 20:11 ` Sven LUTHER
@ 2001-04-01 20:35 ` Bruce Hoult
2001-04-02 10:09 ` Sven LUTHER
0 siblings, 1 reply; 13+ messages in thread
From: Bruce Hoult @ 2001-04-01 20:35 UTC (permalink / raw)
To: Sven LUTHER, Mattias Waldau; +Cc: caml-list
At 10:11 PM +0200 4/1/01, Sven LUTHER wrote:
> > What about using HTML-interfaces
>> instead of standard GUIs like Tcl and GTK?
>
>Well, i think this may be a good idea (sun is doing this) if you need to run
>your code remotely and for system configuration and administration.
>
>But, ...
>
>Most web browser are huge beast, running slowly and ressource hungry. Also i
>think you can do less things with html than you can do with modern toolkits.
>
>Also there is the question of bandwith.
I think cvsweb is a good example.
I'm sitting here in New Zealand on a 56k modem, doing development
work on Gwydion Dylan, with the cvs server being in Germany. If I
want to see, say, the change log for the CREDITS file then I have two
choices. I can type [1]...
cvs -d :pserver:anoncvs@berlin.ccc.de:/home/cvsroot log src/CREDITS
... which takes just over five seconds to fetch the results, or I can
enter into my browser the URL...
http://www.ccc.de/cgi-bin/cvsweb/gd/src/CREDITS
...which takes about two seconds, is prettier, and is more functional
in that I am then only a click (and two more seconds) away from
seeing the source of any version I want, doing diffs between
versions, getting source annotated with who last changed each line
etc.
It's just not obvious that HTML is slower than the alternatives.
-- Bruce
[1] no, of course I don't type all that -- I'm more likely to hit
"C-x v l" in emacs (because Eric Raymond taught emacs how to do
that), and emacs could equally easily be taught how to fire up a
Netscape window with the cvsweb page. (actually, I taught MPW Shell
to do that for me, because I know how to customize it better than I
know how to customize emacs)
-------------------
To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Caml-list] Using HTML as a standard GUI for Ocaml
2001-04-01 20:35 ` Bruce Hoult
@ 2001-04-02 10:09 ` Sven LUTHER
2001-04-02 15:53 ` CREGUT Pierre FTRD/DTL/LAN
0 siblings, 1 reply; 13+ messages in thread
From: Sven LUTHER @ 2001-04-02 10:09 UTC (permalink / raw)
To: Bruce Hoult; +Cc: Sven LUTHER, Mattias Waldau, caml-list
On Mon, Apr 02, 2001 at 08:35:14AM +1200, Bruce Hoult wrote:
> At 10:11 PM +0200 4/1/01, Sven LUTHER wrote:
> > > What about using HTML-interfaces
> >> instead of standard GUIs like Tcl and GTK?
> >
> >Well, i think this may be a good idea (sun is doing this) if you need to run
> >your code remotely and for system configuration and administration.
> >
> >But, ...
> >
> >Most web browser are huge beast, running slowly and ressource hungry. Also i
> >think you can do less things with html than you can do with modern toolkits.
> >
> >Also there is the question of bandwith.
>
> I think cvsweb is a good example.
>
> I'm sitting here in New Zealand on a 56k modem, doing development
> work on Gwydion Dylan, with the cvs server being in Germany. If I
> want to see, say, the change log for the CREDITS file then I have two
> choices. I can type [1]...
>
> cvs -d :pserver:anoncvs@berlin.ccc.de:/home/cvsroot log src/CREDITS
>
> ... which takes just over five seconds to fetch the results, or I can
> enter into my browser the URL...
>
> http://www.ccc.de/cgi-bin/cvsweb/gd/src/CREDITS
>
> ...which takes about two seconds, is prettier, and is more functional
> in that I am then only a click (and two more seconds) away from
> seeing the source of any version I want, doing diffs between
> versions, getting source annotated with who last changed each line
> etc.
>
> It's just not obvious that HTML is slower than the alternatives.
Sure, but guess what you would have used if you wanted to update your Xfree86
source tree to the latest cvs HEAD version ?
Again, like i said, there are a few uses where using html for guis make sense,
but in the generic case, using gtk+ or some other toolkit makes more sense.
Friendly,
Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Caml-list] Using HTML as a standard GUI for Ocaml
2001-04-02 10:09 ` Sven LUTHER
@ 2001-04-02 15:53 ` CREGUT Pierre FTRD/DTL/LAN
0 siblings, 0 replies; 13+ messages in thread
From: CREGUT Pierre FTRD/DTL/LAN @ 2001-04-02 15:53 UTC (permalink / raw)
To: caml-list
That's the way I program GUI now. I found I lost too much time with GUI
that were supposed to be the standard way with CAML (do you remember
Daniel's (de Rauglaudre) RT lib ? the various versions of Tk libs, etc.).
Nowadays there is a browser (Netscape or IE) on any machine and most of the
time it is running anyway. This gives you distributed, multi user interfaces,
may be not for free but at least you will not have to rethink everything when
you need it. Furthermore you really get more independance between the
contents and its presentation than with a regular GUI (unless you are
careful to design your application as two separate sub applications). XML
will improve the situation further.
HTML GUI has weaknesses (handling the back button, old contexts, etc.) but
they are relatively small. For bandwidth : I do not program video games.
So I use a modified version of Daniel de Rauglaudre wserver using threads
instead of fork and a home brew
library for HTML where text is basically a stream of string but HTML
constructs are hided behind functions.
The major task of the library is to hide URLs behind a notion of callbacks
with arguments and maintain notions of contexts (lifetime of a user
interaction).
Drawings are done with Thomas Boutel gd library sometimes with some DHTML
code for layering. Another solution for very dynamic parts is to use
a socket with a java applet (a generic graphics applet would be nice).
Pierre Crégut
PS> Another solution for the HTTP server is to use Jserv and program
an interface between CAML and Apache replacing the Java integration.
This is not difficult but I only experimented it briefly.
The major advantage is that you get all the apache modules for free (for
example so far I only have basic authentification with my server).
--
Pierre Cregut - pierre.cregut@rd.francetelecom.fr - +33 2 96 05 16 28
FTR&D - DTL/MSV - 2 avenue Pierre Marzin - 22307 Lannion Cedex - France
-------------------
To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Caml-list] Using HTML as a standard GUI for Ocaml
2001-03-31 9:31 ` [Caml-list] Using HTML as a standard GUI for Ocaml Mattias Waldau
2001-04-01 12:52 ` Fergus Henderson
2001-04-01 20:11 ` Sven LUTHER
@ 2001-04-02 19:16 ` Gerd Stolpmann
2001-04-03 18:06 ` Mattias Waldau
2 siblings, 1 reply; 13+ messages in thread
From: Gerd Stolpmann @ 2001-04-02 19:16 UTC (permalink / raw)
To: Mattias Waldau, caml-list
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
^ permalink raw reply [flat|nested] 13+ messages in thread