Re: [Ocaml-lib-devel] Future of ExtLib

[Nicolas C. <war...@fr...>]

> Actually, this is a deep problem, and not limited to just compression.  I
> could see reimplementing zlib in pure Ocaml.  But the #2 thing to do is
> encryption/decryption.  For which you should not only call out to C, but
> have the C call hand tuned assembly.
[...]
> So, there are three possibilities:
>
> - Stick with implementing everything in Ocaml.  This gives us
> portability and library independence (you don't need zlib nor gmp
> installed) at the cost of performance
>
> - Allow C/ASM callouts for performance
>
> - Provide both, and some mechanism for choosing between them (with
> the attendent problems)

The problem is also the cost of reimplemeting.
It was little painful for me to have to use the zlib, since I know it will
requires all my sub-projects to compile and deploy some C code : the zlib
itself - but also the CamlZip stubs (for which an Win32 Makefile was not
given). But after looking at the ZLib format RFC, I somehow thought that it
would take me quite a lot of time to reimplement it, and in the end maybe
get a lower quality result (since zlib itself is quite a nice piece of code,
highly suppported and optimized).

If I had enough time, this is what I will do :
- write a small C library that can alloc/access C memory , load dynlinked
libraries, retreive and call functions from it
- add Ocaml interface to this C library
- port this C library to all architectures were Ocaml is working (including
the good compilation parameters)
- add this C library to ExtLib and install it by default
and then we can write all the stubs to external C librairies in pure OCaml
using this small C library ( let's call it EmuC ).
We can then provide a lot of stubs for a lot of different C libraries
according that :
    - theses libraries are dynlinkable
    - they can be accessed using EmuC

Good points :
- theses stubs will be pure ocaml and depends only on EmuC so we are
minimizing the dependencies
- the user can compile the stubs without actually having the library
compiled/installed.
- we only have to maintain and port one file of C code : emuC

Bad points :
- we have to correctly write the stubs in order to support several versions
of the dynlinked library (while only a recompilation would have been needed
for C stubs)
- a little speed tradeoff since we're adding an C layer over every memory
access we're doing

Regards,
Nicolas Cannasse