Tim,

> > Now that KAPLIBS does have a public API, I'd side with David and think
> > that's the obvious place for it rather than compromising NDF.  Rodney
> > would not be pleased!
>
> I chose NDF because:
>
>    1. It seemed to be the obvious place to me since .MORE.FITS is a de
>       facto standard even if it is not actually part of the standard.
>       It's now in common usage. (partly because whilst HDS does allow
>       for typed keyword/value pairs there is no easy way to include the
>       descriptive comment and unit that the FITS header string gives you)

But its a bit like the situation with the old AIPS WCS keywords - they
were in common usage,  but they had never been precisely specified. Are we
sure that all packages which use more.fits use it in the same way? In some
places I have seen it stated that more.fits is simply for keeping a record
of the FITS headers as they existed at the time the NDF was created. So is
it legal to modify the WCS cards in an existing more.fits to take account
of shifts,rotations, etc applied to the NDF since then they no longer
represent the original FITS file? And is it legal to add FITS cards to an
NDF which was not created from a FITS file? Answers to questions such
as these are not so important whilst more.fits is just an ad-hoc
package-specific thing, but would need to be specified precisely if the
fits airlock idea becomes part of the NDF standard. Also of course the
airlock component would need to be moved from MORE otherwise it really
would break the philosophy that MORE is used for stuff which is not part
of the NDF standard.

>
>    2. kaplibs is a bit of a hodge podge and has far more dependencies
>       than NDF. Writing a perl wrapper to this routine is easy if it's
>       in NDF. I'd be happier with ndfGtfts in KAPLIBS if the NDF
>       bits of kaplibs were spun off. I also don't really like the "1"
>       in all the method names and think we should start using "kpg"
>       rather than "kpg1".

I agree that kaplibs is becoming (or is already) a bit of a black hole and
that ideally it should be split up and tidied up. But the question is
whether it is worth the time given the other jobs we're all doing.

> What routines are in KAPLIBS that are doing the job of NDF helper
> routines?

Depends how you define "NDF helper". I would suggest FTS1_AXIS,
KPG1_ASFIX, KPG1_ASGET, KPG1_GTWCS, KPG1ASPRP, KPG1_AXBNx, KPG1_AXTYP,
KPG1_CPNT, ...  (etc,etc,etc)

I suppose one definition would be "has at least one NDF identifier as an
argument, and only depends on those libraries which NDF itself depends
on".


> I'm clearly not going to win this one though...

We're always open to persuasion...

David