[evla-sw-discuss] Implementation languages for the observing layer

[Bill Sahr]

I would narrow Barry's list for scripting-language/
implementation-language combinations for the observing 
layer to the following:

> 
> Python/C++ via CORBA
> This is the route chosen for ALMA.  It has large advantages in that
> CORBA handles a lot of the differences between how things are handled
> in the two languages, and pretty flexibly lets you transmit data
> from the script interpreter to the underlying code.
> 

> XML/C++
> Rather tidy, in that an observation descriptor would suddenly
> appear full-blown as a structure.  But it is less than clear to me
> how to handle differences between antennas (eg to designate a
> reference antenna for holography, and the like), or how to handle
> subarraying.  This can probably be resolved, but it would take quite
> a bit of thought to be sure.
> 

> Jython/Java
> This has the major advantage that the integration seems pretty tight
> (one can just import Java Classes), without having to go through the
> IDL mucking about necessary with Python/C++ via CORBA.  Seems very
> attractive on the surface, but I haven't looked very deeply.
> 
> XML/Java
> Same comments as XML/C++.  Both included here in hopes of inciting a
> religous melee over the question of whether Java or C++ is more likely
> to be around in the far future.

and add, as pointed out by Ramon Creager

<favorite scripting language>/C++ via SOAP

<favorite scripting language>/Java via Soap

As my <favorite scripting language>, I nominate Python which
gives:

Python/C++ via SOAP

Python/Java via SOAP

I haven't given the matter much thought but the combination
of Jython with Java via SOAP may not make much sense since the
integration of Jython with Java is already very tight.

Additionally, I would tend to eliminate CORBA based solutions.
I find CORBA to be an excessively heavyweight solution, and I
suspect that IDL programming is something of a "tarbaby", i.e.,
once introduced, more and more of the software must use IDL,
with the eventual result that it permeates the entire system.

I also tend to favor Java solutions over C++.  For me, the issue
is productivity.  There is good support in the literature for
the assertion that programmers are much more productive in Java 
than in C++.  When I look at the amount of software that must be 
written and compare it to available staff, higher productivity 
becomes a prime consideration.

I agree with the elimination of glish based solutions at least
w.r.t. the interface between the observation scheduling software
(to be developed by e2e) and the monitor and control system.
We may be forced to a glish/C++ combination for issues involving
the archive and the image pipeline by the need to draw upon 
AIPS++ routines in those two areas.  However, I would like to
keep the use of glish & C++ to an absolute minimum.

Finally, if SOAP is used, then the XML based solutions become
somewhat superfluous.

So, an even shorter list would be:

Jython/Java

Python/Java via SOAP

Jython/Java via SOAP if this combination makes sense

with the possible addition of glish/C++ in the area of
the archive and the image pipeline.

Barry's concerns re handling antenna differences and subarraying
for the XML cominations probably apply to the use of SOAP.

Bill Sahr