On Fri, 5 Mar 2004, Giaretta, DL (David)  wrote:

> Mark
>
> Do you have any views on the matter of parameter systems.
>
> My inclination would be to keep with Alan's system unless you see major
> problems, simply because it would affect more apps if we were to change.
>
> ..David
>

David, Al and other stardevvers who may have comments,

<disclaimer>
  I haven't - at least recently - looked in huge detail at JPCS,
  and in particular I don't really know what is involved in writing
  a task which uses it, so the following comments are subject
  to some ignorance on my part.
</disclaimer>

The two systems were written for different purposes - JPCS is a way
of using from Java a parameter system which either is or closely
resembles the ADAM parameter system, while TASK is a way for java
programs to interact with a generic parameter-supplying environment
(though they share ideas of what a task is, what a parameter is, etc).

I would expect my TASK classes to be easier to use when writing
from scratch java programs that need parameters.  TASK certainly
looks less complex than JPCS - this is no doubt a combination of
(a) improved design enabled by features of Java not available to a
system modelled on a Fortran-based system, (b) features which are in
ADAM but aren't really needed, and (c) features not written
becuase it hasn't been much used yet.  Another thing I claim in its
favour is better encapsulation and type-safety - in TASK the
characteristics of a parameter are defined by writing/instantiating
a class, while in JPCS it's done mostly by reading an XML file.
This which enables you to use more inheritance, less reflection.

As a user of Starlink applications as well as a programmer, I've
always found the ADAM parameter system pretty complicated to use
with it's PPATHs and VPATHs and the rest, especially the hidden
state stored the ADAM_USER directory.  We could see now as an
opportunity to come up with something a bit less baroque for the future.
However it may be that my views on this aren't widely held (for instance
because all those features really are needed and I just haven't been
in a position to see this), or that it would simply require too
much effort to do.

For the question at hand: if what is required is a system which can
wrap all existing ADAM tasks in such a way that they can be used
just as before, then it is probably going to be necessary to have a
system that looks like JPCS, or at least much more like that than
my TASK classes.  I'm not sure what the aims of Al's work are; if
he does need to do this, then there is probably only one decision
possible.

Finally: I know that JPCS links to the classic SUBPAR libraries as
part of its build, but I don't know whether it requires this library
to run.  We certainly don't want to be in a position where we need some
platform-specific code for any java applications which use parameters.

The fact that NDTOOLS currently uses TASK isn't really an argument
against switching to JPCS - I don't think anyone has ever used it
except me for test purposes (performance is still very poor apart
from anything else, though this is related to the ARRAY/NDX classes
nothing to do with TASK).

Mark


> -----Original Message-----
> From: Alasdair Allan [mailto:[log in to unmask]]
> Sent: 05 March 2004 03:14
> To: David Giaretta
> Subject: Progress, NAM and other matters
>
>
> Dave,
>
> Progress so far...
>
> I've got a working Java application (which adds a couple of numbers
> together right now) which is sitting in a JPCS parameter system harness
> inside a standalone Jetty/AXIS webserver. This application,
>
>  * figures out a free port, and calculates an authenticaton token
>  * saves the token, host and port number in a file in $ADAM_USER directory
>  * accepts parameters via a SOAP message authenticating the message
>    against the token
>  * adds its two numbers together and returns the result via another message
>    after serialises its GLOBAL and task specific parameters into $ADAM_USER
>  * returns proper SOAP Fault messages if there are problems
>
> token authentication means that only the user who initially ran the
> application can access the web services it provides. Token authentication
> can (of course) be turned off...
>
> Alan's parameter system looks okay, although not exactly the way either
> Tim Jenness or myself would have done it. It's got some rough edges, but
> its more or less shipable as is (with some minor tweaks).
>
> I have JPCS (the parmeter system itself) in StarJava CVS. I haven't yet
> looked seriously at the StarTask JNI wrappers for native applications.
>
> That, unforunately, looks alot less polished...
>
> The ORAC-DR side of things is going okay, I have a perl test harness for
> this test java application which works fine. I'll start on the ORAC-DR
> classes on Monday, hopefully should have a working CATSELECT replacement
> ready to go before I leave.
>
> I don't know what you want to do with respect to Mark's "other" parameter
> system called 'Task'?
>
> You need to make a management decision here, as there isn't much point
> pushing this work much further if we're going to dump JPCS next month
> anyway. After looking at the two systems I sort of agree with Mark that
> you couldn't really merge them sensibly.
>
> The StarTask (JNI wrappers for Classic) stuff would probably have to be
> rewritten if we dump JPCS in favour of Mark's Task system, as it relys on
> JPCS to provide a plugin replacement for SUBPAR.
>
> On the other hand Mark's NDTOOLS would have to be rewritten if we dump
> Task in favour of JPCS. I don't think Task is used elsewhere in StarJava
> (yet), but we need to decide now (soon?) which one we're going with...
>
> Unfortuantely, I don't think I'm sufficiently familiar with Task (or JPCS
> come to that) to say which is technically better...
>
> Cheers,
> Al.
>
> PS. Remember that I go on holiday a week today (Fri 12th) all the way up
>     till NAM. So if you want FROG related stuff out of me for the Starlink
>     demo posters you'll need to talk to me about what you wantmore or less
>     first thing on Monday.
>

--
Mark Taylor    Starlink Programmer     Physics,  Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/