From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 95927BC6B for ; Wed, 9 Jan 2008 10:22:11 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFMhhEfUGyodimdsb2JhbACQGwEBAQgEBiIHgRSXXw X-IronPort-AV: E=Sophos;i="4.24,261,1196636400"; d="scan'208";a="7595191" Received: from smtp3-g19.free.fr ([212.27.42.29]) by mail3-smtp-sop.national.inria.fr with ESMTP; 09 Jan 2008 10:22:11 +0100 Received: from smtp3-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp3-g19.free.fr (Postfix) with ESMTP id 06DF317B583; Wed, 9 Jan 2008 10:22:11 +0100 (CET) Received: from [192.168.0.3] (rke75-3-82-229-183-156.fbx.proxad.net [82.229.183.156]) by smtp3-g19.free.fr (Postfix) with ESMTP id C431C17B55F; Wed, 9 Jan 2008 10:22:10 +0100 (CET) Message-ID: <47849135.8000605@frisch.fr> Date: Wed, 09 Jan 2008 10:17:41 +0100 From: Alain Frisch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Shared run-time DLLs for commerce References: <200801071130.29025.jon@ffconsultancy.com> <200801071503.26977.jon@ffconsultancy.com> <47824B45.1000507@frisch.fr> <200801071951.25170.jon@ffconsultancy.com> In-Reply-To: <200801071951.25170.jon@ffconsultancy.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; frisch:01 frisch:01 run-time:01 ocaml:01 ocaml:01 lambda:01 dependencies:01 lambda:01 low-level:01 pervasives:01 abstracted:01 dependencies:01 functor:01 stdlib:01 functor:01 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