From JMV to Metcast

We move away from a single outstanding request mode.

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, packed.dat, request.mfr, *.xxG etc. files have to be created/placed in the folder for the area they pertain to, rather than NODDSFLS.

There seems to be no need for ARQ_info.txt


Sample JMV/Metcast session

A Metcast user defines an area of interest and selects weather products: grids, 3D and shaded products, wind directions, etc.; he may also pick METAR and TAF real-time synoptic observations and (real-time) satellite imagery. This area definition and product selection process is virtually identical to the one in NODDS. As in NODDS, the user is in no way limited in what areas of interest he can outline and which products he can ask for (of course, whether these products are currently available for a given area is another matter; if a request cannot be fulfilled entirely or in part, a Metcast server will say so).

The user configures the retriever, for example, through an "Option:Network" pull-down menu of a JMV shell. Necessary configuration info:

All this configuration information is stored in a retriever configuration file, which is a plain text file (and may be edited in any text editor).

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.

The retriever performs an HTTP transaction, as described in the standard HTTP protocol. Specifically, it:

If real-time product updates were requested, the module does not exit. After sleeping for a user-specified time interval, the retriever performs 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.

If the 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.

The 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 retrievers.


Requesting products

Process Data module

JMV shell

RTO merging module

This is the module that is supposed to make sense of Content-type: text/x-syn data type. It is implemented as a syn-proc MIME helper

Display module

No changes seem to be necessary


$Id: MigrationPath.html,v 1.3 1999/10/05 19:10:33 oleg Exp oleg $