Sign inRegisterCheck connection

Cumulus Gadget Feeds as Tiny Observation Payloads

Google Gadget and sidebar feeds carried a tiny Cumulus observation packet into a third-party container. Trust, caching, and why those containers died.

Back to Cumulus weather software guides

A gadget feed is not a station homepage and it is not a research archive. It is a tiny observation payload written so a third-party container—Google’s iGoogle gadgets, a Windows Sidebar gadget, or a similar host—could show temperature without rendering the full Cumulus site. The historical path /gadgetfeed.php was that payload generator on the Cumulus host.

This article is about the container contract: how small the document had to be, who was trusted to fetch it, how caching made “live” weather stale, and why the gadget era ended. It is not the Cumulus RSS project (how to generate a feed from Cumulus files) and it is not the served RSS endpoint (what a feed consumer should require). Those pages share XML on the wire. They do not share this job.

Historical context

In the late 2000s a personal weather station site was often too heavy for a sidebar. Operators wanted a box on an iGoogle homepage or a Vista/Windows 7 desktop gadget that showed outdoor temperature, humidity, and maybe a wind arrow. The container, not the station site, owned layout, refresh, and the user’s identity. The station owed the container a small, repeatedly overwritten document.

The Cumulus Wiki realtime.txt page lists a sidebar gadget among the third-party consumers of that optional one-line packet. Other gadgets subscribed to a short RSS-like or XML fragment produced by PHP from realtime.txt or from processed web tags. The historical TNET Cumulus host exposed /gadgetfeed.php in that role. The original gadget XML and any ZIP of gadget manifests are not rehosted.

Google launched iGoogle (a gadget-bearing homepage) in 2005 and announced its retirement in July 2012, with shutdown on 1 November 2013 (Google blog; iGoogle developer note, last checked 13 August 2026). Windows Desktop Gadgets were removed from later Windows versions. The scientific problem—publishing a bounded current-conditions packet to a host you do not control—did not disappear. The specific containers did.

A payload, not a channel

A full station RSS document can carry a channel title, a site link, a description, and an item that tries to be a complete observation contract. A gadget feed is smaller on purpose. The container had a few hundred pixels and a refresh timer. Typical contents were:

  • one temperature and its unit;
  • humidity;
  • pressure or wind, if space allowed;
  • a short valid-time string;
  • sometimes a link back to the station site.

That is a status fragment. It is closer to realtime.txt than to a weblog. If the gadget host asked for RSS, the document might still be RSS 2.0 in the sense of a <rss> root (RSS 2.0), but the intent was not syndication of many items. One item, overwritten, was the usual design.

Do not confuse this with Cumulus XML. The webtag dump is a large named-element export. A gadget payload is a subset chosen for a viewport. Dumping every webtag into a gadget is how you blow a bandwidth cap and freeze a sidebar.

Trust: the container is a third party

Once you publish /gadgetfeed.php, any client that knows the URL can fetch it. In the gadget era that client was often Google’s servers or a desktop gadget runtime, not the visitor’s browser. Three trust problems follow.

You do not control the fetch identity. A container may strip cookies, ignore Cache-Control, or fetch from a datacenter far from the station. Geolocation of the request is not the station location. Put latitude and longitude in the payload if the gadget needs them; never infer them from the gadget host.

You do not control rendering. If the payload includes HTML in a description, the container may execute markup you did not intend. Keep observation fields in plain text. Escape &, <, and >. A temperature string does not need a <script>.

You do not control retention. A gadget platform can cache the last successful body and keep showing it after the station is down. From the visitor’s point of view the gadget is “live.” From a data-quality point of view it is a stale observation with a missing freshness label. The honest payload includes the observation time. The honest gadget UI shows that time, not only “now.”

A personal weather station is not an official warning service. A gadget that displays a Cumulus Zambretti-style forecast phrase next to a temperature without labeling the phrase as software-derived is mixing observed and scenario information. NWS (or the national service with authority at the site) remains the warning source.

Caching is part of the observation

Gadget platforms refreshed on their own clocks—often minutes, sometimes longer. Cumulus realtime generation can be seconds. Those intervals should not be pretended to match.

If the gadget host polls every 15 minutes, publishing realtime.txt every 10 seconds does not make the gadget a 10-second instrument. It makes an expensive upload path whose last sample is then held. Align the extra-file timer with the container’s poll, or accept that the gadget shows a subsample.

HTTP caching still applies when the container honors it. A Cache-Control max-age longer than the observation interval is a published lie. A gadget feed should:

  • set a max-age on the order of the station upload gap;
  • include Last-Modified from the source file (realtime.txt or processed XML);
  • prefer conditional GET if the container sends If-Modified-Since.

If the container ignores headers, the payload must carry pubDate or an equivalent valid time so a later human can see the lag. That is the same freshness discipline TNET states for public records on data sources, quality controls, and methodology.

Why gadgets died (and what did not)

Gadgets died because the hosts were withdrawn, not because current conditions stopped mattering. iGoogle’s shutdown removed a homepage that third-party weather gadgets had targeted. Desktop gadget runtimes were dropped from later operating systems. Remaining “widgets” are mobile OS tiles, iframe embeds, or JavaScript gauges that fetch JSON from the same origin—different containers, same payload problem.

What remains valid:

  • A compact, unit-labeled, timestamped current-conditions packet is still the right object for a small display.
  • realtime.txt is still the Cumulus file designed for that job, when enabled (wiki).
  • A third-party fetch is still a trust boundary. If a modern map or app pulls your packet, document units, time, and coordinates the same way you would for a gadget.

What should not be restored:

  • a Google Gadget manifest that assumes google.com/ig;
  • a Windows gadget package of unknown license;
  • PHP that emits a feed for a platform that no longer exists, while claiming the station is “live in iGoogle.”

The Cumulus hub keeps the historical map of these projects. For the full RSS generation workflow, use projects.rssfeed. For what a remaining feed URL should contain, use rss.php.

Practical checklist

  1. Decide whether you still have a container. If not, retire the gadget URL as documentation, which is what this page is.
  2. If you still emit a tiny payload for an embed, source it from realtime.txt or a small extra template—not from a full webtag XML dump.
  3. Put units and a valid time in the payload. Do not rely on the container’s clock.
  4. Treat the container as untrusted HTML. Plain text observations only.
  5. Cap output size. A gadget that pulls 56 kB of XML every few seconds is the bandwidth failure the XML webtags wiki already warned about.
  6. Label derived forecast phrases. Do not let a sidebar imply an official forecast.

How TNET frames observed versus derived information in its own public research is described conceptually on how the service works. This gadget URL stays a lesson about small payloads and third-party hosts.

Sources