Okay, it's Christmas so I'm thinking "what would users really want me to
implement in my Christmas holiday" and my answer is "stop Starlink apps
from being so stupid when faced with blah.sdf on the command line".
So I have a couple of questions:
1. Where is the best place for me to trap ".sdf"?
2. Can it be faked in the "foreign formats" stuff?
3. Do I just change HDS or do NDG and NDF need patching as well?
Sicne the argument has always been "what if someone has a .SDF component
in their HDS file?" my answer is:
1. No-one is seriously that stupid
2. HDS is designed to be self describing so presumably we just use
datThere for ".SDF" and if it is there we use it else we just ignore
it and open the file anyway.
3. Far far more people would "praise the skies" if we did this than
would get upset with their ".SDF" component ambiguity.
You only get a real problem if someone has a ".SDF" component *and* they
don't actually want to open it when they say "blah.sdf" but in that case:
1. "blah.sdf" will be doing what it does now (ie opens the .SDF
component)
2. They always needed to use "blah" without the ".sdf" before
and that will still work.
So I can't see any obvious case against patching this. I've had a quick
look at the maze of twisty passages that is NDF/NDG but am not sure
exactly what to patch. Naively, rec1_attach_file should be modified to
ignore ".sdf" (rec1_get_path adds it back on).
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|