Civic duty done for the day: turning down a conservative fundraiser, on account of Bill C-13/Bill S-4 on warrantless surveillance.

Let's follow up a previous prototype, turning that work upside down.

In our first visit to the fantasy land of PCP+Graphite, we created web renderings of PCP data by a small python script periodically polling PCP information, relaying it to the graphite carbon network-server/database, and letting the carbon server talk to the graphite web-app. It looked like this:

There are a lot of parts - at least three separate server processes between the web browser and the data. Each of those servers requires configuration, firewalling, and other such care & feeding. Each uses cpu/memory/disk and adds latency. This is probably fine if the graphite/carbon installation is already the centerpiece of one's monitoring installation, and PCP is only a subordinate data source.

But what if PCP is the data source, and we're just looking for a pretty web gui for it? This is not far-fetched - PCP can efficiently ingest data from many other systems (and expel it again in original form). Can we have a simpler installation?

Why, yes.

PCP's pmwebd server is a relatively recent addition to the toolset. Its original job has been to bridge the PCP client API to web applications through a JSON API. It included a little baby fileserver for hypothetical webapps to use that API, though we only included a toy set of blinkenlights.

The new and improved pmwebd over at this git branch has been learning one extra trick. It has learned to answer several of the graphite web-api protocol commands that the carbon & graphite server-side code normally answers, and maps them to queries against the underlying PCP dataset. No python, no carbon, no httpd.

How to run it? Build pmwebd from the src/pmwebapi directory, after running the top-level configure (so the cairo library dependencies are found). Then choose any directory containing PCP archives. (This can include nested subdirectories, as produced by the pmlogger_daily or pmmgr tools. Thanks to recent work by Ken McDonell, this can include archives being written-to at the same time, so close to "live" data.) Then run:

% ./pmwebd -G -R jsdemos -A /path/to/archives
	Started daemon on IPv4 TCP port 44323
	Using libmicrohttpd 0.9.33
	Serving non-pmwebapi URLs under directory /path/to/pcp/src/pmwebapi/jsdemos
	Remote context creation requests enabled
	Archive base directory: /path/to/archives
	Graphite API enabled with Cairo graphics
	Periodic client statistics dumped roughly every 300s

Then sic a web browser at http://localhost:44323/. That's it. You may run as many copies of pmwebd as you like, with different port numbers.

How does it look? Well, just like graphite, or grafana, a peer web gui that works on the same server interface. An unmodified release snapshot of each is included with pmwebd sources. Not every feature in the web apps is implemented yet or perfectly emulated, but the basics are there. One can zoom in/out, put together dashboards of info.

The pcp-to-graphite namespace mapping is straightforward: the top level graphite name identifies the individual archive file; middle levels identify the pcp metric; the last level (if appropriate) identifies the instance of the pcp metric. Only numeric types are currently supported; events should come at some point, as should connection to live PCP collector (pmcd) processes rather than just to archives.

This last one, a zoomed-in view for your humble scribe's workstation, is displaying 100% genuine oscillations related to this PCP infrastructure bug in the process of affecting this very pmwebd. Spot the pigeon.

We must be one of the most prolific users of the local public library, something like 20-50+ items out on loan all the time, the boys speed-reading (?) through them whenever they don't do homeschooling work or other activities. We've even used to receive automated calls from the library suggesting we don't borrow quite so much, out of consideration for others, or something. Sometimes our returns require baskets (due to weight & volume).

But that's just the present. It started with crazy-early literacy for the boys, and a particular event I wish I were there to record, soon after we moved to our current town. 1.8-year-old Eric visited this library for the first time. I'm told his eyes opened wide, stood there stunned for a minute, and then started running up to, around, and thankfully not through all the aisles. He is reported to have yelled "books, books, books!" the whole time. But since I wasn't there, and for some reason photography is verboten in the building, so it wasn't recorded. We'll just have to imagine & recall.

Our family saw Alice through the Looking Glass at Stratford the other day. It was very pretty, the staging was clever and imaginative, the actors were good (though an Alice closer to her calendar age might've been nice, and seeing so many male actors grin in drag was weird), the surprise presents for the audience were surprising, and the recorded music was well-recorded.

The play however ... I just couldn't get into it. I'm a fan of Monty Python and Douglas Adams and even Lewis Carroll, so absurd/witty nonsense is A-OK with me. But on stage, this one doesn't seem to work. With some such material, one needs time to reflect upon it. But with the live stage, there is no pause button and no rest for the eyes. Much of the repartee seemed sort of perfunctorily confusing, as if it was simply taking pleasure in constantly not making sense, as opposed to being satirical or even funny. And character drama? Hardly any.

But I'm no theatreologist, so don't believe me.