From: mholdawa@truchas.CV.NRAO.EDU (M Holdaway)
Subject: Where do we go from here
Date: Mon, 16 Mar 92 14:35:38 EST




1)  EXTEND THE PROTOTYPE!
	Most of our effort in this prototype has been put into
	making self-consistent sub-systems.  Very little
	effort has gone into making sure these subsystems
	can interact with one another in a simple and clear
	manner.  It is my opinion that we need to push this
	"exercise" further.  While I understand the time
	constraints on the report, we are really writing
	the report before we have finished the object of
	the report.  And the last steps of putting it all
	together are by no means just "academic"...they
	are fundamental, and will tell us what is wrong
	with the class design.

2)  A BROADER DEEPER 2ND PROTOTYPE!
	Our feet are wet.  Lets go for a more intense system
	that has more than one TelModel and possibly more than
	one Imaging Model.  Multiple models are needed to test
	the "associators" scheme.  Also, this enters into the
	realm of "detailed instrumental requirements":  we could
	have one imaging model for the VLA and one for a linear
	array like AT or WSRT;  we could try to do polarization
	calibration for the VLA and WSRT.  [I am actually a bit worried
	about polarization.]
	And finally, I think that we NEED to get some spectral
	line stuff into the prototype.  One of the biggest fears
	in Socorro is that AIPS++ would not be much better than
	AIPS at dealing with spectral line data.  We NEED to
	get spectral line on board as early as possible!

	If we break everything down into YEGS, we need to
	be damn clever at reconstructing the QUADS and the
	SPECTRA.


3)  A BROADER SYSTEM REQUIRES OBJECT PERSISTENCE!
	We at least need to be able to write out images, visibility
	data sets.....so that we don't fall into the ONE MAIN PROGRAM
	syndrom.  (Bob Sault suggests FITS readers and writers.
	This would also enable us to work with some real data
	sets.  Performance could be tested against SDE
	which has a very flexible timer.)

4)   GET THE REAL PROGRAMERS ONBOARD!
	We should get Mark S and Bob P
	involved in THIS prototype...so we can test out their
	wares, so we don't have to design vector classes, so
	we can tell them what is useful and what is hard to
	use.  Also, the last two points dealt with
	"associators" and object persistence.  This would be
	a good place to deal with the DATABASE and get Chris
	onboard.

5)  MORE INTER_GROUP COMMUNICATION!
	In the past, systems such as this one were designed
	by 1 or 2 people working in close cooperation.
	While communication inside each group seems to be
	fine, communication among groups is not good.
	I think shifting the group lines will only change
	the lines accross which communication does not
	easily flow.  It may help, but wont solve.


It is my feeling that the more complicated and realistic a system we
are dealing with, the more complicated and realistic problems
we will uncover.  There will always be hacks and fixes that can
be applied to these problems, but that is EXACTLY what broke
old AIPS.  If AIPS++ is to be the best system we can write
at the present time, we need to program the next prototype as
much like a real (but limited in some particular ways) system
as we can.


Here is my suggestion for a timescale:

	Spend 2.5 months designing, building, and evaluating
	the next prototype.  Work on the current prototype
	would wind down as work on PROTO++ winds up.

	By June 1, we need to have evealuated this prototype
	and be in a position to start AIPS++.  I imagine
	a good deal of code will be reused from PROTO++
	to AIPS++ if PROTO++ is designed with polarization and
	spectral line in mind.  If the code cannot be reused,
	then we must consider ourselves lucky for
	doing such a broad prototype.

	By July 1, we will have the bones of the real system.
	We will know how polarization and spectral line
	data and images fit together.  It is difficult enough
	to convince colleagues that there is a problem when
	we talk to each other FACE-TO-FACE!  If there are
	still major design flaws after July 1, we will
	have a LOT OF TROUBLE WORKING THEM OUT!
	Hence, I support a very ambitious PROTO++.




	-Mark Holdaway