From rz48@rz.uni-karlsruhe.de  Mon Apr 15 12:34:38 1996
Received: from ratatosk.DK.net (ratatosk.DK.net [193.88.44.22]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id MAA16791 for <sc22wg5@dkuug.dk>; Mon, 15 Apr 1996 12:33:10 +0200
Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by ratatosk.DK.net (8.6.12/8.6.12) with ESMTP id MAA06356 for <sc22wg5@dkuug.dk>; Mon, 15 Apr 1996 12:32:49 +0200
Received: from ry73.rz.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de 
          with SMTP (PP); Mon, 15 Apr 1996 12:28:50 +0200
Received: by ry73.rz.uni-karlsruhe.de (1.37.109.16/16.2) id AA225414124;
          Mon, 15 Apr 1996 12:28:45 +0200
Subject: RPC-like interlanguage calls
To: sc22wg5@dkuug.dk
Date: Mon, 15 Apr 1996 12:28:44 +0200 (CES)
Cc: clodius@nis.lanl.gov, laifer@rz.uni-karlsruhe.de
From: hennecke@rz.uni-karlsruhe.de
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Content-Length: 2938
Message-ID: <"nz11.rz.un.632:15.04.96.10.28.57"@rz.uni-karlsruhe.de>

Last week, William Clodius sent me a pointer to a tool called
ILU (Inter-Language Unification) developped at Xerox PARC, at

  ftp://parcftp.parc.xerox.com/pub/ilu/ilu.html

I briefly reviewd that work, and found it very similar to other
"distributed computing" methods (at least in those aspects that concern
our interoperability issues). ILU, similar to other methods like
NCS (Network Computing System) and of course OSF's Distributed Computing 
Environment (DCE), do a connection of "client" and "server" by 

 o Providing bindings to an abstract interface description language, called
   IDL (Interface Definition Language) for DCE, NIDL for NCS, and ISL for ILU.

 o Doing tha actual "connection" by generating "stubs" for both the client and
   server part, which then call the actual user code (stubs can but need
   not necessarily involve networking).

If my memory serves me right, this is NOT the way WG5/X3J3 wanted to address
the Fortran/C interoperability issue. This philosophy is based on two very
important facts: 

 o There is a HIGHER-LEVEL instance which defines the data types on a more 
   abstract level (this may be compared to WG11's Language Independent 
   Data-types), and 
   
 o BOTH sides of the call need tayloring. This includes mapping to the
   abstract datatypes of the interface definition language as well as
   "wrappers" to do the actual call.

My understanding of the WG5 project was that we should try to find a way
to use existing C code without modifying the "server" part (X Windows,
system calls, ...) and hopefully without generating C stubs (by the user).
Should people disagree with this interpretation, then please email me.

Nevertheless, It might be of interest for Fortran users who want to use a 
remote procedure calling mechanism like the above that a collegue of mine
has developped a tool to use the DCE remote procedure calls from Fortran:
It defines a Fortran Interface Definition Language (FIDL) which is closely 
modeled after Fortran 90 procedure interfaces, and the C-like IDL interface
definition and all C stub code is generated from that. 
This tool is described in detail at

  http://www.uni-karlsruhe.de/~Roland.Laifer/fidl/index_e.html

  ( For the next 4 weeks, enquiries for FILD may be addressed )
  ( to me because Roland is out of the office until May 9.    )

Best regards,
Michael
 
 ======================================================================
  Michael Hennecke      http://www.uni-karlsruhe.de/~Michael.Hennecke/ 
 ----------------------------------------------------------------------
  University of Karlsruhe         RFC822: hennecke@rz.uni-karlsruhe.de 
  Computing Center (G20.21 R210)           BITNET: RZ48@DKAUNI2.BITNET 
  Zirkel 2  *  P.O. Box 69 80                 Phone: +49 721  608-4862 
  D-76128  Karlsruhe                               Fax: +49 721  32550 
 ======================================================================