Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] RE: OCaml on CLR/JVM?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Arturo Borquez <aborquez@a...>
Subject: Re: [Caml-list] RE: OCaml on CLR/JVM?
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