From JMV to Metcast

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

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

• URL of a Metcast server, in the regular URL format, or broken down into separate fields: server site name or an IP address, port, and the absolute resource path
• Name or IP address of a proxy server (if necessary)
• A checkbox: would a user stay online waiting for reply, or prefer the products delivered asynchronously (via e-mail). E-mail address should be provided then
• A checkbox if the user wants to authenticate himself to the server.
  If the checkbox is marked, a user ID and the password should be entered in the corresponding fields
  (assuming the Basic WWW authentication scheme)
• Two time specs, limiting the number of products received from the server to the ones modified within the given time intervals. The first time spec refers to the initial request the client makes to the server, the second time spec is for recurrent requests that may follow. This second time spec, if not empty, turns the retriever into a polling (looping) mode, and specifies how frequently to poll for (real-time) product updates.
  For example, if the first field specifies 10 hrs, and the second field contains 1 hr, the initial request delivers products that were created/refreshed within 10 hours; every hour after that the retriever would 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.
  If the second time spec field is empty or disabled, the retriever would 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.

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

• establishes a connection to an HTTP server (or a proxy server)
• sends a request
• waits for reply; if the request was successfully fulfilled, this reply would contain requested weather products, packed into a MIME message. The retriever unpacks and decodes them, using an appropriate helper(s)
• closes the connection

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

• Create request.mfr in the area folder rather than in the parent folder (NODDSFLS)
• Call the retriever passing it request.mfr's path name and the name of the retriever's configuration file, as described on the retriever's "man page".
  For example, to request products/updates for area NORF, the request module should spawn/exec()
retriever retriever.conf NORF/request.mfr
  assuming that the requestor is running from NODDFLS, JMV's working directory.
• Add a description of the METAR (RTO) product into FIELDLST.DAT file, as follows

  MZZ REAL TIME OBSERVATIONS           000000100040000000000000000000000000000XXX
  0 0000 9999 9999 100000000 0000 0000 0000 020 0.00
  

  Thus a user can request METAR observations just as he requests any other product: temperatures, grids, upper-air reports, etc.

Process Data module

• The process data module would be launched like
  jmvprocess NORF /var/tmp/aaaa0000
  It receives the name of a JMV area folder as the first command line parameter, and the path to a packed.dat file as the second parameter. The latter has the format of packed.dat, but probably would not be called literally like that.
• The jmvprocess module would be launched as a Content-type helper, by the retriever (or by Netscape or other Web browser, or by any MIME-compliant mail program) to handle Content-type: text/x-packed-dat
• The jmvprocess module should first descend to the area folder.There, it may get on with its regular duties: splitting the packed.dat file into *.xxG files, creating missing.dat file if necessary, converting *.xxG into *.xxF files, and creating a fldsum.dat.
  Note, all processing should be done entirely within the area folder; all temporary files are to be created in this folder, rather than in the parent (NODDSFLS) directory. This also means that the jmvprocess module should look for request.mfr file in the area folder.

JMV shell

• Implement a special Configure:Request menu item to let a user enter/modify the URL of a HTTP server and other parameters (authentication info, frequency of receiving updates, etc). These parameters are to be stored in the file NODDSFLS/retriever.conf, which is read by the retriever module
• When the user selects Retrieve data menu item, the shell should launch the requesting module and let it run in the background. The shell should not wait for the module to terminate (because the retriever can run for a long time, especially if periodical updates are requested).
  The shell should probably minimize the requesting module window, if possible.
• When the shell module itself exits, it should kill all running retriever modules

RTO merging module

Display module

History

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