Re: Ada95 Streams Question

[michael@ifr.luftfahrt.uni-stuttgart.de]

Robert Dewar <dewar@GNAT.COM> wrote:
> "I have connected an Ada95 executable to a C++ executable using streams. The Ada
> is the brains of the application, and the C++ is the Motif pretty face. On both
> sides I have defined a set of portable types which application types are
> converted to for transmission and converted from on receipt."
> 
> This should work reasonably reliably with GNAT, cannot say for other
> Ada 95 compilers which might do something completely different for
> stream rerpresentations of primitive data.
> 
> It is a bit of a puzzle to us why you don't just use a procedural
> interface. It would be MUCH more portable, and MUCH more efficient

Of course I can only speculate why such an approach might make sense for the
original poster of this question (I don't know who that was) but I can say
that I can think of a lot of reasons to try this because we are facing
exactly the same problem.

We are in the busyness of vehicle trajectory optimization. The software package
we have developed for this purpose manly consists of two parts. One part, which
the original poster called the "pretty face", is the graphical user interface
which controls the whole operation of the software and the second part is
"the brains of the application" which does all the numerics and contains
the user provided procedures to describe the vehicle model. When you are
working with a model this "brain" has to be recompiled and relinked several
times and this process is controlled by the "pretty face". According to
this setup it obviously makes sense to keep these two parts separate and not
link them into one big executable. But, when the "brain" is working it has to
closely interact with the "pretty face" which is, e.g. showing the progress of the
optimization process.

The two processes are connected with each other via files and pipes and it
would now be very elegant to use streams to read and write the data. I always
thought that this is exactly what streams are made for.

A further advantage of this separation is that you can run the "brain" on
another computer, maybe a high performance server. This kind of distribution
seems to be quite natural to me but I sometimes have the feeling that the Ada
community has not yet understood the benefits of distribution and client server
computing.

The first problem arises when you try to exchange stream data files between
computers of different architectures. This is just not foreseen by the Ada 95
standard (see implementation advice in RM and current practice of GNAT).

For the described setup it would be even more elegant to utilize an implementation
of the distributed system annex but as this builds on the stream facility as well
you face the same problem as mentioned above. If you just look at the wording
of this annex the big picture is a huge monolithic program that is now broken
into pieces (partitions) and executed as a whole on a homogenous network of
computers. That is definitely not what I understand by distributed computing.
Although this could certainly be interpreted in a more open way, this is
exactly what is currently implemented for GNAT.

This is not meant as a criticism of the GNAT team. They do a marvelous job and
just implemented what the standard suggests. I just want the Ada community to
reconsider the real "openness" of Ada with respect to heterogeneous computer
environments and client server computing.

Michael

-- 
------------------------------------------------------------------------
--Dipl.-Ing. Michael Paus   (Member: Team Ada)
--University of Stuttgart, Inst. of Flight Mechanics and Flight Control
--Forststrasse 86, 70176 Stuttgart, Germany
--Phone: (+49) 711-121-1434  FAX: (+49) 711-634856
--Email: Michael.Paus@ifr.luftfahrt.uni-stuttgart.de (NeXT-Mail welcome)