Re: [Caml-list] Shared run-time DLLs for commerce

[Alain Frisch <alain@frisch.fr>]

Jon Harrop wrote:
> Yes. The concern here is not loss of sales but loss of competitive edge. With 
> direct access to a comprehensible implementation of the complex algorithms 
> inside the software, people will nick the algorithms even if they don't nick 
> the source code. After 9 years of work, I'd rather not see that happen... :-)

If your target audience is people who already use OCaml (and who come 
with request for support for specific versions of OCaml), I doubt you'll 
get direct competition on this niche, so it should be safe to ship the 
source code. If you target the widest audience of people looking for 
good visualization solutions, you might want to drop the tiny fraction 
of those who insist on using an old version of OCaml. Anyway, that's 
none of my business.

> I was thinking that externalizing an interface to the intermediate 
> representation might be another solution?

The first intermediate language where pattern matching is already 
lowered (the lambda code) already has strong dependencies to specific 
interfaces (e.g. it makes to references fields of external modules by 
position).  Moreover, there is no guarantee that the internal 
representation of this lambda remains compatible across versions of OCaml.

> In many cases a separate server would work well. However, this is an 
> OpenGL-based application so I think this would require one process to be able 
> to render efficiently into an OpenGL context from another process. I'm not 
> sure how or if that can work or whether or not it would be portable.

Cannot you put the low-level OpenGL part in the main process (shipped 
with source code) and the high valued algorithms in the server?

> I'd be very happy if the brittle digest comparison were replaced with a 
> structural API comparison instead. That would save me a lot of time and 
> effort.

Compiled code depends on specific locations for elements coming from 
external modules. Basically, if a version of OCaml adds a new field 
around the top of Pervasives, the code compiled against the old version 
becomes invalid.

What you can do is to ship your library as a single module abstracted 
over all its dependencies (that is, a functor which takes as arguments 
modules from the stdlib and other dependent libraries). You can put in 
the interface whatever you expect from these modules, so the same 
functor could be used with future versions if they only add new fields
(but not new constructors or record fields, for instance). Again, some 
Camlp4 hack could somewhat automate this.

The module still depends on a specific version of OCaml, but now, it 
could make sense to add to the compiler features to read and write
version-independent representations of .cmi and lambda-code files.
(But honestly, I don't believe this will happen in the official OCaml.)


I've a final suggestion:

- automate the compilation of your library for several versions of OCaml 
and of dependent libraries; it's not as if there were 200 versions of 
each to support, 5-6 should be enough, right?  A single command could be 
enough to compile and package your library for all the possible 
combinations. If you write a generic and robust tool for this task, you 
might even be able to sell it.  Now, your customers would get a small 
installer that checks their installed versions and download the relevant 
version of your library.


-- Alain