Sign inRegisterCheck connection

The TNET WAP Project: Cumulus Observations on Feature Phones

TNET's historical WAP project brought Cumulus observations to feature phones under WML and tiny-payload limits—not the serving deck at /wap.php.

Back to Cumulus weather software guides

Before smartphones made a full Cumulus website merely “small,” a large fraction of phones spoke Wireless Markup Language over WAP, with decks of a few hundred bytes, grayscale screens, and no expectation of PNG banners. The historical TNET project at /projects/wap was the engineering effort to put Cumulus observations on those handsets: a tiny payload, a card-and-deck model, and a data path from web tags or realtime.txt into WML.

This page is the project. Serving a deck to whatever device is calling—content negotiation, what a complete observation looks like on a small screen—is /wap.php. The second-generation markup (XHTML Mobile Profile, early smartphone CSS) is /wap2.php. Three URLs, three jobs.

Historical context

WAP 1.x browsers expected WML, not desktop HTML. A WML document is a deck of cards; the phone typically holds one deck at a time and navigates between cards without fetching a new site chrome on every glance (WAP Forum WML 1.3). Gateways could further encode WML as WBXML. Screens were narrow, often 96–128 pixels wide, with fonts you did not control.

Cumulus, meanwhile, published HTML templates and optional realtime files sized for a PC browser. The TNET WAP project existed because those PC pages were the wrong object: too many images, too many tables, too many bytes for a circuit-switched or early packet data session. The project’s output was a constrained publisher—PHP or processed templates emitting WML from the same observations the web-tags project was already binding.

TNET does not rehost a WAP toolkit, a WBXML encoder, or a ZIP of decks. Feature-phone WAP is not a current product surface. The constraints remain a clean lesson in what an observation record must still contain when the canvas almost disappears.

Engineering constraints that shaped the project

Payload. A WML deck that pulled in the default Cumulus website’s images would fail on memory and on the carrier bill. The project’s first cut was therefore subtractive: no GD banner, no webcam, no JpGraph, no CSS file. Text fields from a processed include or from realtime.txt only. The Cumulus Wiki notes that a classic realtime file is well under a kilobyte; that packet is already close to a whole WAP response if you serialize it as labeled lines instead of as a desktop table.

Round trips. Each card fetch could cost seconds on 2G. The project therefore preferred one deck with a few cards (now, today’s extremes, maybe wind) over a menu of ten URLs. That is the opposite of a modern single-page app and the opposite of a 468×60 hotlinked banner that hits PHP on every forum view.

Character repertoire. WML and early phone fonts were poor at ° and at Unicode. Unit tokens from Cumulus (C, F, mph, hPa, mm) were safer than decorating with a degree sign that became ?. The project’s typography problem was repertoire, not TrueType hinting.

Navigation model. Cards are not HTML sections. A “Back” key returned to the previous card in the deck. Designing a Cumulus WAP project meant deciding which observations share a card so that Back still made sense. Putting rain-year on the same card as now-temperature mixed clocks; putting every extra sensor on its own card multiplied latency.

Input. WML could include fields and WMLScript; a weather project did not need them. Read-only observations avoid posting from a handset into a logger. The TNET project is a publisher, not a remote control for Cumulus.

Images. WML allowed small WBMP images on some devices. A thermometer or avatar in WBMP would have been a different GD product with a two-color gamut. The WAP project as a payload exercise is text-first. Identity images stay on their own URLs.

Data path from Cumulus to a deck

The project did not invent a new meteorology. It reused the Cumulus contract:

  1. Cumulus writes a processed extra file or realtime.txt on its timer.
  2. The web host reads that local file (not a live socket into the logger).
  3. A template emits WML with a short list of labeled values plus units plus a time.
  4. The phone gateway may recode the markup; the observation must survive recoding.

That is why the project sits next to extra web tags rather than next to webcam galleries. If the include is stale, the deck is stale. If the include uses MX error strings for unknown tags, the deck must not present those strings as temperatures.

Hardware interval still wins. EasyWeather-class stations on the order of 48-second updates do not become “live WAP” because the deck is small. Small is about bytes, not about sampling.

What the project is not

It is not a claim that modern TNET operates a WAP gateway. It is not /wap.php’s discussion of Accept headers and completeness. It is not /wap2.php’s discussion of why a second markup family needed a second URL. It is not a recommendation to build new services in WML; the Open Mobile Alliance’s later browsing specs moved authoring to XHTML Mobile Profile and treated WML2 as compatibility, not as a green-field language.

It is also not an official warning channel. A feature phone is a fine place to read a station. It is a bad place to imply that a PWS deck replaces NWS or local emergency alerts.

Design rules the project had to obey

These rules are the usable remainder of the historical work:

  • Prefer the same field names and units as the web-tag vocabulary so WAP, banners, and HTML cannot drift.
  • Cap the now-card at a handful of scalars: temperature, wind (named), pressure or rain—not both extra-sensor arrays.
  • Always ship a time and a unit, even if the screen is four lines. Completeness is defined in the serving article; the project’s job was to refuse a design that omitted them to save bytes.
  • Fail closed on missing data. An empty card that looks like calm weather is a false observation.
  • Do not embed forecast-number expansions as if they were METAR. Label station-program scenarios.
  • Keep the deck cacheable on the order of the Cumulus interval. A WAP gateway that cached aggressively could outlive the packet; HTTP freshness still applies (RFC 9111).

Modern relevance

Native phone browsers ended the need for a parallel WML site for almost all operators. The project’s intellectual remainder is constrained publishing: when the network or the device is poor, you still owe units and a clock, and you still must not upload a desktop page. That lesson shows up in off-grid stations, in emergency text-only views, and in any API that thinks a 200 OK with three unlabeled numbers is enough.

How TNET describes observed versus modelled versus derived information in public is how the service works. Grouping the atmospheric fields you would even consider putting on a four-line deck is evidence families. Source freshness for the file behind the deck is data sources and methodology. The Cumulus hub lists the related historical pages.

If you need to serve a small-screen observation today, start from the completeness rules on /wap.php and the markup split on /wap2.php, not from a restored WML ZIP.

Sources