Sharing a pico engine

Let's begin by riffing off the title of the previous post, "The passage of time." Almost a year of time has passed since that past post. During that time, my personal pico has been busily collecting temperature readings at the rate of 30 per hour (so, we're talking a quarter million events).

Meanwhile, Phil Windley, the inventor of picos, and a world-class expert in identity and authorization, has been busy improving those aspects of the pico engine. So, there are many updates to consider. The pico engine had been stable at version 1.3 for nearly three years when he released version 1.4 in June of this year (2026), followed monthly by versions 1.5.* and 1.6.*. In this post, we'll be talking about version 1.5.

The passage of time

In the post Scheduling events, we were responding to this desire: "it would be more convenient if the pico could just wake up every morning, check for ...".

The problem is that a pico isn't aware of the passing of time. It is not until some event comes for it — from the world outside of it — that the pico will do a computation in reaction to that event. After that reaction, it becomes quiescent again, until the next event or query.

In the earlier post, we showed how a ruleset can schedule future events, like we might set an alarm clock. The schedule is maintained by the pico engine, and when a future time arrives the pico engine will send the event to the pico to wake it up. This allowed the pico to do something every day at the set time.

This post will explore the idea of a simple ruleset that acts like an old-time town crier. It will send an event at the top of each hour of the day (and night). Like the crier shouting out "Ten o'clock and all's well!" Rules can then select on this event so that the pico can do things as often as every hour.

Detecting an unwanted condition

An earlier post, Managing channels, ends with the observation that "perhaps there should be monitoring in place, so that if no readings have come in during some period of time the pico's owner could be notified by text or email." This recently became an issue because of a different failure mode with a similar symptom.

In the earlier case, an error in managing channels made it so that no temperatures were recorded for hours on end. A few days ago, just one of the sensors stopped sending temperatures for several hours before this was noticed and days before someone could go on-site to reset it.

This post will show how to watch for the situation where readings are not received from one or more sensors for over an hour. It is easy to react to an event, but harder to react to something not happening.

We are going to layer on a ruleset that will send an email message to the pico's owner when it notices that expected readings have not arrived.

Building a web application

In this post, we'll build a simple web application using the pico stack.

This example is built by layering a new ruleset onto a pico hosted by the Pico Labs Affiliate Network (PLAN), where applications are only for private viewing (whilst logged in to an account therein).

Here we show how to program a public web page within that same pico.

APIs revisited and wonders of the web

There have been several posts about Application Programming Interfaces (APIs), but little explanation or motivation.

Everyone knows that the world wide web is bursting with useful and interesting information. Generally we get this information in our browser. 

Besides the countless websites that we enjoy with the browser, there are many more sources of information that are out there, on the web, but do not have a human-facing presentation. To consume these, you must have a program that uses their API.

Tutorial for a new application

When learning a new programming language, it is customary to start with a "Hello, World!" program.

This tutorial will guide you through this process for the KRL programming language^* used with picos.

How to make money hosting picos

In the third note of an earlier post on Managing channels, we promised this post.

Basic economics

Buy low; sell high.

Running a pico engine in an AWS EC2 instance will cost a few dollars a month. Such a site could host thousands or probably even tens of thousands of picos. So, sell control of a pico for ten dollars a year and you should be able to make a profit.

Managing your KRL code for rulesets

When using PicoStack, code and data are combined within a pico. Together they represent some entity, which is responsive and reactive.

The code is written in KRL, the language you will need to learn (after having learned enough HTML, CSS, and JavaScript to get started). Since KRL itself consists of ASCII text (except in character strings and comments (where you can insert other UNICODE characters)), you can use your favorite text editor or  integrated development environment (IDE) to write your code.

Besides maintaining this code on your own machine, you will probably want to use a code repository in the cloud. This post explores possibilities.

Web API needing a token grant

Web APIs that follow the OAuth pattern need special treatment.

Besides needing a client id and client secret, API calls that do actual work require a bearer token, which is generated by a special call to the API.

So, using such an API is a two step process:

1. Given the client id and secret, request a token
2. Supplying the token, make the API call that does actual work

While one could do the two steps for each actual API call, it is better practice to store the token from the first call in an entity variable and then use it in each API call that does actual work.

The end of programming?

While this blog has so far been mostly timeless, I'm going to comment here on a current event: an article arrived today in my mailbox, titled "The End of Programming"^* and subtitled, "The end of classical computer science is coming, and most of us are dinosaurs waiting for the meteor to hit," written by Matt Welsh.

I'm arguing that the use of PicoStack to develop small web applications could continue, long after most computer applications are developed using artificial intelligence (AI) techniques, and code is being written routinely by AI agents instead of humans.

Managing channels

A previous post, Pico channels, defines and describes channels, and prescribes some best practices for managing them. 

This post tells a story of bad consequences when that advice was ignored^*, and also describes a more resilient way to set up the channels for one particular application.

Consider a pico that records temperature readings from remote sensors. The sensors need a channel to post their readings periodically. A web application allowing the history of those readings to be explored also needs a channel to the pico.

Notifications

Each pico, from the moment it is created, is a first-class Internet resource, exposing a rich API of events and queries. It maintains a boundary between its internal state and the outside world.

When something interesting happens inside the pico the owner/controller of the pico may want to be notified.

A previous post about sending email illustrated this for that notification method. In this post, we'll discuss sending a message into a Microsoft Teams channel. Similar techniques can be used so that our pico can notify other message systems.

Scheduling events

Picos are a good fit for applications that have a relatively small amount of state for each entity, and that perform relatively quick computations, relatively infrequently.

Web applications fit that profile. From time to time, someone requests information about the state of an entity. That state is expressed as a web page, and that doesn't take a lot of time to compute.

Every so often, an event occurs that is of interest to the entity, and the pico reacts to that event by changing its state, which also doesn't require a lot of compute time.

Sometimes, though, we'll want the entity's pico to spontaneously wake up and do something. This is where scheduled events come into play.

Sending email via a web API

This is part four in a series^* on using web APIs to accomplish useful things in a PicoStack web application.

We have talked about consuming web APIs in a read-only fashion, safeguarding web API secrets when they are required, and wrapping the complexity of an API in a ruleset used as a module.

In this post, we'll use all of these techniques and demonstrate how to use a web API to send simple text email messages.

Wrapper opportunity

When using a web API it can be nice to have a wrapper around the various HTTP requests that can be made.

On the plus side, this allows for a separation of concerns. Your code doesn't need to get into the details of making the HTTP requests.

Often, the provider of the web API also supplies wrappers for various popular programming languages. Some, like TMDb (used in the previous post) accept wrappers from their developers and list them for use by other developers.

Web API secrets

In the previous post, we consumed a web API which was provided freely (which we called "public") in that it didn't need to know who we were. Most web APIs require consumers to identify themselves, and do this by giving out an API key and/or client secret.

The identifiers we will obtain from an API provider are intended for our use only, and we are responsible for that usage. In this post, we'll show a couple of ways to keep them secret while we consume such APIs.

Consuming web APIs

There are countless thousands of APIs provided on the web. Fifteen percent of them are public^*. A web application can consume private ones once you have signed up with the owner of the API and been given client API keys and secrets.

Either way, PicoStack is an easy way to consume these APIs.

In this post, we'll walk through using one particular public API, which provides information about events held at Brigham Young University (BYU).

Website Certificates

Your website will need a certificate if you want to use TLS to encrypt traffic so that it cannot be intercepted and read -- or worse, modified -- as it flows from a browser to your picos and vice versa.

If you elect to use TLS, the browser will show your visitors that your website is "safe"^* because your URLs will be able to use the HTTPS protocol, rather than the unencrypted HTTP protocol.

To use TLS, you need a certificate which offers proof that you control the web server which hosts your picos and hence your website. A certificate authority will issue you such a certificate after verifying that you do indeed control the web server.

Session information

A web application, when in active use, is a large decentralized system. Thousands (and hopefully more) of participants, each with their own machine running a web browser, are generating events to -- and requesting resources from -- the web server portion of the web application.

It can become centralized if the web server controls who can access the web application. This doesn't have to happen; it is a decision (whether consciously or unconsciously made) by its designers.

Relationships between picos

In the previous post, we described pico channels. When you have the identifier of one of a pico's channels, you can use it to send events and queries to that pico.

When a pair of picos need to work together, each needs an ECI (event channel identifier) to the other. The bundle of that pair of ECIs reifies a relationship shared by the two picos. Each pico has its own copy of the bundle.