RE: XML, HTTP, SOAP (was RE: JIT-compilation for OCaml?)

RE: XML, HTTP, SOAP (was RE: JIT-compilation for OCaml?)

[Dave Berry]

Here at KAL we do develop many of our applications using scripting languages
in IE, as you describe.  But within this we embed ActiveX controls or
Javabeans that provide significant functionality (e.g. business logic or
device control).  The script handles the events generated by the embedded
components.  So this is an example of advanced web programming that does
require explicit language support, and if you wanted the same program to run
on different architectures you would need a VM (or multiple
architecture-specific installations).

-----Original Message-----
From: Mattias Waldau [mailto:mattias.waldau@abc.se]
Sent: Wednesday, January 10, 2001 9:12
To: Dave Berry; John Max Skaller; Markus Mottl
Cc: OCAML
Subject: XML, HTTP, SOAP (was RE: JIT-compilation for OCaml?)


> Dave Berry wrote

> 3.  Web programs require interfacing to web browsers.  Perhaps someone
>     could add the OCaml VM to Mozilla?

I don't believe we need Ocaml as a VM, I am not even sure that Java will
exist as a VM in the future. Most advanced WEB-clients today are coded using
Javascript (or sometimes VBscript).

Thin clients is a good approach! By implementing the Ocaml-program as a
multithreaded HTTP-server which exports its functions using XML or SOAP
(typed rpc over HTTP encoded by XML), very advanced interfaces can be done
easily.

The client consists of a Javascript program, or stylesheets or some of the
newer XML-technologies.

If you restrict yourselves to modern browser (ie 5, netscape 6), there are
good nice way reducing the amount of javascript coding. One example is HTC.

These kinds of interfaces can both be used locally (http://localhost) or
over the internet. Performance is very good locally, I know from practical
experience.

Creating a table using HTML is very often much easier than creating a user
interface with a listbox with columns and filling it.

/mattias

RE: JIT-compilation for OCaml?

[Dave Berry]

Dynamic libraries would be useful, but there are other areas where OCaml
(and most if not all other FLs) falls short.  See below.

Regarding C/C++ interfacing, this should be do-able, it's just a lot of
work.  What might be useful would be if all the implementors of advanced
programming languages (OCaml, SML, Dylan,...) got together and wrote a tool
for generating IDL from C/C++ header files.  Then each implementor could
write a language-specific IDL translator.  I know the Dylan community made
some headway with parsing header files.

Here are some application areas to consider:

1.  Huge numbers of commercial programs are simple UIs on top of simple
databases.  Hence the success of VB.  A UI builder and simple DB interface
would meet this need.  (This is easier said than done).

2.  A smaller number of commercial programs are complex UIs on top of
complex databases.  Here a UI builder is less important, but a UI toolkit
and a sophisticated DB interface are essential.

3.  Web programs require interfacing to web browsers.  Perhaps someone could
add the OCaml VM to Mozilla?

4.  A growing number of commercial offerrings are based on component
technology (ActiveX controls or Javabeans).  Support for these (or perhaps a
native equivalent) would be very useful.  (Again, this is easier said than
done).

5.  There are many embedded programs out there.  These are tricky to write
with a GC.

Dave.

-----Original Message-----
From: John Max Skaller [mailto:skaller@ozemail.com.au]
Sent: Tuesday, January 09, 2001 6:40
To: Markus Mottl
Cc: Mattias Waldau; OCAML
Subject: Re: JIT-compilation for OCaml?


Markus Mottl wrote:

> > If Ocaml had a decent GUI API that worked on just X- and MS- Windows
> > systems, it would be a killer. 

> I expected that people would mention GUI-libraries, but I don't write
> GUIs. Is this really everything people are missing?

	Actually, no, there are some other significant
problems (apart from education) with Ocaml. 

	1. The lack of dynamic loading virtually wipes it out 
as a serious commercial language (IMHO). 
This can probably be fixed.

	2. The difficulty of interfacing to existing
C/C++ code. This probably cannot be fixed. [For example,
consider the sheer volume of work required to map GTK
to Ocaml]

	There are, of course, many other problems, such as
the lack of intermodule recursion, but all languages have
various difficulties which can usually either be fixed
or worked around. 

	But clearly the biggest problem is one of education,
both of the virtues of functional programming, and the details
of the ocaml syntax/semantics (much of which escapes me, after
several years usage).

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

XML, HTTP, SOAP (was RE: JIT-compilation for OCaml?)

[Mattias Waldau]

> Dave Berry wrote

> 3.  Web programs require interfacing to web browsers.  Perhaps someone
>     could add the OCaml VM to Mozilla?

I don't believe we need Ocaml as a VM, I am not even sure that Java will
exist as a VM in the future. Most advanced WEB-clients today are coded using
Javascript (or sometimes VBscript).

Thin clients is a good approach! By implementing the Ocaml-program as a
multithreaded HTTP-server which exports its functions using XML or SOAP
(typed rpc over HTTP encoded by XML), very advanced interfaces can be done
easily.

The client consists of a Javascript program, or stylesheets or some of the
newer XML-technologies.

If you restrict yourselves to modern browser (ie 5, netscape 6), there are
good nice way reducing the amount of javascript coding. One example is HTC.

These kinds of interfaces can both be used locally (http://localhost) or
over the internet. Performance is very good locally, I know from practical
experience.

Creating a table using HTML is very often much easier than creating a user
interface with a listbox with columns and filling it.

/mattias