English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] COM binding & CAMLIDL ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-05-18 (09:48)
From: Xavier Leroy <xavier.leroy@i...>
Subject: Re: [Caml-list] COM binding & CAMLIDL ?
Hi Samuel,

> Reading a recent thread on the list, I noticed that ocaml could be
> used with COM components on windows. As I currently intensively use
> the Python COM bindings with MS' text processor whose name I won't
> say, I wonder if I could use ocaml to the same end.
> However, the release notes in the ocaml-win distribution states that
> the cygwin version lacks COM support, and the native win32 version
> partially implements the libraries, among which I find no COM nor IDL
> link. Does anyone on the list have more information ?

In the Windows world, there are actually two flavors of COM, the
inter-application communication framework:

- "Pure" COM, which uses native C data representations, and is
oriented towards statically-known, statically-typed IDL interfaces
from which stub code can be statically generated.

- Automation, which uses Visual Basic data representations (the
"variant" universal type used by VB to represent its data), is
dynamically typed, and is often used in a context where the IDL
interfaces are dynamically discovered.

Both flavors are loosely related -- Automation uses a fixed "pure" COM
interface called IDispatch to implement remote invocation -- but quite
different in practice.

CamlIDL implements (most of) the "pure COM" approach, but is geared
towards statically-typed, statically-known interfaces (on ne se refait
pas, as we say in French), and is not suited to Automation.

Microsoft applications use mostly (exclusively?) Automation to allow
scripting.  The reason is that Microsoft pushes Visual Basic as the
scripting language for their applications, although non-Microsoft
dynamically-typed scripting languages such as Perl and Python have
also been quite successful at that,

A Caml interface for Automation seems feasible, and actually could be
simpler than the CamlIDL "pure COM" interface.  I know of at least two
serious users of Caml that are interested, and one of them is
considering to host a summer intern to work on this.  So, stay tuned.

- Xavier Leroy
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners