A poor man Metcast Client

This document was originally an e-mail message sent on Jun 23, 1999 to a large group of people.
 

I was playing with a Metcast Request Language and a web page I set up to make this more fun. Somewhat unexpectedly I discovered that we have had a Metcast Client all along. Not the one that requires a computer with 50MB of RAM. We have a client that has already been ported to almost any possible platform, including PalmPilot and similar handhelds. Quite possibly we can fetch and display, for example, an Advanced Tropical Cyclone Warning on a Nokia cell phone right now.

Request-Lang-Forms.html

I wrote this page mainly for myself, to make it easy to play with the Request Language. The page presents a bare-bones form to enter an arbitrary request language phrase, which you can submit to a Metcast server. The page also has a number of 'canned' requests. Try for example to get the latest METAR observations from around Monterey. When you press the corresponding submit button, the browser will send the request and ask you what to do with a reply of type text/x-omf. You can save it in a file, or open in any application: XML notepad, for example, or a text editor. You can also tell the browser to remember your setting and not to ask you again.

But there is more: try to execute a request that says 'Get Tropical Cyclone Warnings'. Prior to that, I instructed Netscape to open text/x-tc-warnings documents in a text editor. After I submitted the request, I was treated with a spectacular display of 21 windows, each containing a separate tropical cyclone warning.

Thus, a regular web browser submits a request to a Metcast server, unpacks the result and saves it into a file or passes it to a helper application. Doesn't this look exactly what a MetcastClient and OmniRetriever do? Only the browser typically asks what to do with a product it doesn't know how to handle, while the MetcastClient simply ignores such data.

Although I always suspected that a browser may handle multipart MIME entities (which are defined in MIME standard), I wasn't sure until I tried. It was a pleasant surprise, and a clear demonstration why it does good to follow public standards.

Let's return to the Request-Lang-Forms.html page. A user may link to this page from where it is now. At this location, the page is subject to modifications by me as the author. I can add more canned requests and adjust bounding boxes any way I wish. Note however that all the pre-canned requests are editable. If you'd rather see METAR reports for an area other than Monterey Peninsula, simply modify the bounding box before submitting the request. Furthermore, a user may download the page to his local computer and customize the page to his heart desire. He can add requests he wants, and set the areas he is interested in. In this case, the page becomes this local user's own profile.

There is no need of course to display a request language phrase as it is, "in your face". The MBL text can be stored out of sight in a hidden item on the form, with a thumbnail or some other icon shown in its place. The Request-Lang-Forms.html page can become rather user-friendly. Furthermore, instead of a request language phrase, the page may present a colorful form with buttons to select products, levels, taus, etc. The area of interest may be drawn as a map (rather than given as a set of four numbers). The request language clause that reflects user selections can be generated by a simple Javascript. In spite of my aversion to Javascript I think the task above is a very fitting application for it.

Granted, a standalone Metcast Client application is far more flexible. The poor-man browser solution however has an advantage of being able to run on almost any platform, including PalmPilot and similar handhelds. We can fetch things from Metcast channels, display imagery and observations reports on these tiny computers -- not tomorrow, not when we manage to fit 50MB+ RAM onto them, but right now.

$Id: History-MClient-Lite.html,v 1.2 2000/03/22 22:32:05 oleg Exp oleg $