As several requests can be concurrently active (polling several areas for new updates),
all files that are specific to an area have to be in that area's folder. That is,
*.xxG etc. files have to be created/placed in the folder for the area they pertain to, rather than
There seems to be no need for
The user configures the
retriever, for example, through an "Option:Network" pull-down menu of a JMV shell. Necessary configuration info:
retrieverinto a polling (looping) mode, and specifies how frequently to poll for (real-time) product updates.
retrieverwould submit a follow-up request gathering one-hour updates (if any). These follow-up requests would be initiated without any additional user interference, in the background.
retrieverwould submit only one request, process the response, and exit.
Having set the
retriever's configuration, the user launches this module, passing the configuration file and a request file (which specifies the area of interest and selected products). One may do that from a command line, as described on a
retriever's "man page". The user may also use an appropriate GUI, for example, a JMV shell; in that case, the user simply selects a "Retrieve Data" pull-down menu, which launches a new
retriever module in the background. The user may still monitor its output if desired.
retriever performs an HTTP transaction, as described in the standard HTTP protocol. Specifically, it:
retrieverunpacks and decodes them, using an appropriate helper(s)
retrieverperforms the request all over again: opens a connection, sends a request line for updates since the last request, listens for a reply, processes it, and goes back to sleep.
retriever successfully received and decoded a product, it (as normally configured through the mailcap file) launches a viewer (e.g, JMV) to display the area and the data. If the viewer is already running, it is told to refresh its display. Thus one can configure a
retriever to run in the continuous mode, sit back and view real-time synoptic observations, satellite imagery and other data as they are automatically delivered and displayed. The Metcast system along with a viewer run like a "screensaver", constantly updating the display as new data arrive; this is very similar to Pointcast.
retriever constantly logs what it is doing and how successful it is in its transactions. The log can be viewed in a shell window, or in a special JMV window (if the module was launched through JMV; the window would usually be iconified).
One may run concurrently as many copies of the
retriever as one wishes
to, with each copy talking to its own (or the same) Metcast server, each
having its own polling interval, each asking for its own set of
products, which may refer to the same area of interest, btw.
If a retriever was launched through a JMV shell, the shell does not normally waits for the module's termination. When the shell itself exits however, it kills all the running
request.mfrin the area folder rather than in the parent folder (
request.mfr's path name and the name of the retriever's configuration file, as described on the
retriever's "man page".
NORF, the request module should spawn/
retriever retriever.conf NORF/request.mfr
NODDFLS, JMV's working directory.
FIELDLST.DATfile, as follows
MZZ REAL TIME OBSERVATIONS 000000100040000000000000000000000000000XXX 0 0000 9999 9999 100000000 0000 0000 0000 020 0.00Thus a user can request METAR observations just as he requests any other product: temperatures, grids, upper-air reports, etc.
jmvprocess NORF /var/tmp/aaaa0000
packed.datfile as the second parameter. The latter has the format of
packed.dat, but probably would not be called literally like that.
jmvprocessmodule would be launched as a
Content-typehelper, by the
retriever(or by Netscape or other Web browser, or by any MIME-compliant mail program) to handle
jmvprocessmodule should first descend to the area folder.There, it may get on with its regular duties: splitting the
missing.datfile if necessary, converting
*.xxFfiles, and creating a
NODDSFLS) directory. This also means that the
jmvprocessmodule should look for
request.mfrfile in the area folder.
NODDSFLS/retriever.conf, which is read by the retriever module
Content-type: text/x-syndata type. It is implemented as a