> kaplibs, rather than ndf? As you say, putting them in ndf seems to break
> the philosophy of the NDF library which says that anything in MORE is
> beyond its control. The whole notion of a FITS extension is really a
> KAPPA thing rather than an NDF thing. To do this job properly would
> involve introducing a proper FITS component to the NDF structure,
> analagous to WCS, HISTORY, etc.
The extension concept wasn't full grasped and only a few are in use,
largely tied to specific packages. The FITS airlock, as it became known
had wider applicability (e.g. Keith Shortridge adopted it at AAO, used
by CONVERT), and perhaps we should have allowed that one exception from
the start in the NDF (SGP/38) design, but as a .FITS component rather
than an extension; we were adamant that the "can't think of everything"
philosophy was correct. Users wanted and expected the headers to be
available in some form, hence I wrote various FITS airlock manipulation
tools.
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!
Malcolm
|