From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA26621; Wed, 6 Nov 2002 20:57:10 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA27023 for ; Wed, 6 Nov 2002 20:57:09 +0100 (MET) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from smtp.easystreet.com (easystreet.com [206.26.36.40]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id gA6Jv8516438 for ; Wed, 6 Nov 2002 20:57:08 +0100 (MET) Received: from easystreet.com (dial-206-103-35-169.dial.easystreet.com [206.103.35.169]) by smtp.easystreet.com (8.11.2/8.11.2) with ESMTP id gA6Jv4D22122 for ; Wed, 6 Nov 2002 11:57:04 -0800 (PST) Message-ID: <3DC97461.7D694203@easystreet.com> Date: Wed, 06 Nov 2002 11:58:25 -0800 From: achrist@easystreet.com X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: caml-list@inria.fr Subject: Re: [Caml-list] OCaml on Windows please advise References: <20021104212354.44502.qmail@web20504.mail.yahoo.com> <005901c284ef$c7cebc60$6e00a8c0@warp> <3DC80A15.84B8C129@easystreet.com> <005c01c285c5$ff0ae1f0$6e00a8c0@warp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Nicolas Cannasse wrote: > > You should perhaps consider packaging your Delphi GUI into a DLL with > exported function and then have the OCaml Runtime be your startup. This is the problem with many of the non-mainstream languages. Compatible with ... is the the assertion, but the but is 'as long as I get to be on top.' With a GUI application, it is far more natural (ie ignorant of other architectural possibilities, it seems to me to be an easy choice) to have the user in charge, ie the user as the client, and to have the various services (algorithms, databases, etc) in servers fulfilling whatever requests the user hurls in through the GUI. This design seems right because, with this type of design, the servers can be de-coupled from the UI and can serve through the GUI or through any of various other kinds of clients that we might create. With a fancy user-centric GUI in a DLL called from the OCaml runtime, we've got 2-way coupling through some kind of callbacks (don't we? How would that work?), and that's 1 more way than we really need. IIRC, coupling is bad. An alternative is to have the server be a separate executable and to have the client just pipe data through it using stdin, stdout, or various files. But the overhead of starting and waiting on an exe makes this somewhat unattractive if the services are not fairly coarse-grained. Your idea is a good one if the GUI is not user-centric. For example, the so-called 'wizard' applications are task-centric, where there is a predefined sequence of inputs required to complete a task and the user gets led through the steps page-by-page or screen-by-screen. I suppose that this kind of GUI could be rolled into a DLL that worked well without callbacks. But a system that relied on that style excessively would not be one that users liked. I think that this issue is part of a larger culture clash between the unix/linus and Windows/GUI worlds. A strength of Unix/linux is that it offers many small, reliable, single-function programs. Windows succeeds by giving the user the feeling/illusion of control, letting them pick from many options at every turn, open and close Windows willy-nilly, etc, etc. This is a lot for OCaml to take in. > It seems easier because of the following : > > - if you want an ocaml interpreter, you have to link your Delphi with Don't want an interpreter. Last I saw, COM was one of the best things that MS had conceived. That's extremely faint praise, but COM does look to be a good way to partition a system into cohesive parts. With Windows as it currently exists, being able to do COM as both a client and a server would be a very nice feature for just about any language that targets Windows. IDK if MS is going to de-emphasize COM and steer us toward building systems out of .Net components that talk SOAP. Is SOAP a viable and competitive alternative to COM for creating servers/services with OCaml under MS-Windows? Al ------------------- 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