one or two modest proposals.

[nelson%bnlmcn.dnet@bnl.gov (Mitchell C. Nelson)]

Recently two suggestions have come to me. They both seem worthwhile.

One suggsetion, by Robert Fleming, is to develop a common command syntax
and vocabulary. With only a little extra effort we could probably expand
this idea to include a  common set of widgets,  menus, etc... This seems
to me, to be  the best  route to the kind  of  commonality that we would
like to see at the APS.

The second  suggestion  was that I  should  talk to John  Quintana about
implementing DAS using tcl/tk.  After talking to John, it seems that the
two architectures are  quite compatible with  each. But, it occurs to me
that one could actually do a lot better than just a straight port of DAS
to tcl/tk, and with a lot less effort.

So here is the combined proposition:

To use tcl/tk for our purposes, we  really only need to supply a handful
of  compiled code  modules.  The  macro-language  in tcl  seems to offer
everything  else that  one would  need to  develop an  attractive set of
commands, widgets, menus, etc.

Both the  tasks,  of  developing these  few  compiled code  modules, and
designing the command  set and gui's, are  activities that could be done
in an efficient and timely way by us as a community.

So, I'm willing to send anybody who would like to join either or both of
these efforts, a  prototypic command set,  and/or a list of the routines
that we think we need.

Perhaps Robert Fleming will be willing to coordinate the command set and
gui  discussion.  And John  and I could  keep  track of the  code module
specifications and who's working on which code modules.

The ground rules  would be that  all codes are  written in ansi-c and/or
tcl/tk and that all sources are given for free use but not for re-sale.

Some other  considerations that  we've developed are  that we would like
the result to be transportable, and that we would like to use the 'igor'
interface style for gui's where feasible and appropriate.

'Transportable' here means,  layered on EPICS, rather than imbedding one
in the other  in an  inextricable way. By  this  approach, we hope to be
able to implement the system off-line or at our home institutions, using
alternative hardware interface packages.

'Igor' is adapted as a  user-interface style  because most of the people
that we've talked to seem to like it.

A  conservative  estimate  of the  compiled  code   development seems to
indicate a total  investment of just a few  person-months. John seems to
feel that the tcl/tk  codes are much less work  than even that. Deciding
on the command  set, given our  starting point, will  probably take us a
few weeks.


Regards to all,
M. C. Nelson