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 HAA04609; Mon, 5 Mar 2001 07:00:28 +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 HAA04414 for ; Mon, 5 Mar 2001 07:00:27 +0100 (MET) Received: from c012.sfo.cp.net (c012-h018.c012.sfo.cp.net [209.228.12.166]) by concorde.inria.fr (8.11.1/8.10.0) with SMTP id f2560Q929158 for ; Mon, 5 Mar 2001 07:00:26 +0100 (MET) Received: (cpmta 23026 invoked from network); 4 Mar 2001 22:00:24 -0800 Date: 4 Mar 2001 22:00:24 -0800 Message-ID: <20010305060024.23025.cpmta@c012.sfo.cp.net> X-Sent: 5 Mar 2001 06:00:24 GMT Received: from [206.49.216.243] by mail.altavista.com with HTTP; 04 Mar 2001 22:00:24 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: caml-list@inria.fr From: Arturo Borquez X-Mailer: Web Mail 3.9.0.19 Subject: Re: [Caml-list] RE: OCaml on CLR/JVM? Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hi all folks: Perhaps I am wrong, but let me state what I believe about this stuff. Microsoft .NET strategy is an intra Microsoft issue to scale-up VB they are trying stop VB app developers to switch to java. C# is not really important as it will never reach the 'mass' of VB. The real issue is continuity of the actual Client/ Server model that holds distributed processes and a more and more sophisticated (complicated) middleware layer. In my oppinion this model has no future, the real battle is at the server side, so clients would become minimal-device support to interface server apps across the net (ultra-thin-client), with a diverse and broad family of client devices (terminals). So OS interoperability (independence) is very important because the real (active) apps will reside in the Server side (they will drive terminals as has being done in the past [minitel, VTs, CICS ...]) and Caml is doing it yet (UNIX, WINDOWS IBM mainframes OSes missing?). I think this is the 'confuse age' that will be clarified in the next few years. We need a new enhanced version of TCP/IP (or something similar), a standard message system and protocols as simple and effective as possible (deal only with data) to do client to host and host to host interactions. Message translations (mappings) redundant service resolving and assignment, load balancing can be performed much more effective with dedicated communication front-ends than language interoperability or ORB's and stubs in both sides apps. Perhaps new versions of OSes will embbed this issues. My conclusion is CLR/JVM, CORBA RPC ... are not important for the future of Caml, as all will die. Caml will need only some library updates to match the communication tech upgrades. The big argument is cost. Actual Client/Server costs a factor ~ 1.5 (develop, maintenance, deployment) compared with old dinosuar mainframe (CICS), and that why some important enterprises still deploying these systems. The technical argument is that in the actual Client/ Server model the NET is inserted in the wrong position so your app becomes broken in somewhat the 'middle'. To correct this mistake you must put the NET outside the app (or the app inside the Server), and the Client device only runs the 'client-applet' the server sends for that particular app (Client request). Regards. Arturo Borquez Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr