John Taylor replying to Mike Fitzpatrick:
>> IRAF networking's done this for 20 years: resources can be
>> addressed as "node!whatever" and the system internally accesses
>> the remote resource (tape drive, file, image display, etc). The
>> 'whatever' could still be a URL or local file name, it could even
>> be an appName.
>
> Maybe an approach similar to this would work better then.
The ubiquity of this approach should be emphasized. Later developments like the whole "web" thing have stolen some of the thunder, but few (if any) alternatives are as sweeping in their implications as IRAF networking. Any resource (not "some", not "most", not even "virtually any") can be expressed remotely. The programmer would have to work - rather hard - to disable this feature. (I won't belabor caveats - e.g., not permitted to cd to a remote disk - but none of the ones I'm aware of are intrinsic to the architecture.)
The IRAF CL has a foreign command escape - IRAF networking allows you to run the command on any host (has to have IRAF installed, of course).
Any IRAF input can be remotely targeted. Any IRAF output can be remotely targeted. A filter style command that reads input, does something, and writes output can move data from one remote host to another. You might be better off going direct from point A to B without passing through C, but the point is that you can do it.
You not only can remotely copy data without firing up a facility like scp or ftp with special syntax - just type the same command you would locally - you can consult a remote df command beforehand and a remote directory listing afterwards to confirm the transfer.
And it isn't just the IRAF command line that benefits. You can specify remote resources for any task parameters and keep remote log files, for instance. The NOAO High Performance Pipeline relies on IRAF networking for similar purposes.
The ICE package is used to control several CCD cameras on Kitt Peak. Newly minted observations of the sky can be written onto remote disks of computers that don't have ICE installed, that don't connect to a CCD controller, that may not even be located on the same mountaintop. Metadata for FITS headers from various sources could be retrieved from remotely sited central repositories. Few observers might use these facilities, but the point is that these possibilities exist simply because ICE is layered on IRAF. The application doesn't have to know anything whatsoever about networking because the system does.
A task that requires access to a catalog can reference an observatory or community-wide resource, very similar to the concept of a URI - except that no special server has to be installed beyond the basic IRAF system.
My point isn't to chat up IRAF - obviously I'm a loyal alumnus - my point is that such a deeply realized networking facility creates opportunities that you may not even know you're missing. These are the sort of quasi-magical opportunities that users are going to expect from the VO.
Rob Seaman
NOAO
Received on 2007-04-30Z16:56:27