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.
When we say that a pico is "on the Internet" we mean* that it presents an API to the world. A key part of every API request is an Event Channel Identifier (ECI) for the pico. It is a random-looking string that gives access to and authorization for each usage of one of its many** APIs.
Each pico can have an unlimited number of channels. Each event and query comes into the pico via one of these channels. Each channel has a policy, listing which events and queries will be accepted over it.
This post provides specific detail to follow up on an earlier post about picos as the database of a web application.
Each pico holds persistent state, which is data or information specific to whatever entity it represents. Even if the pico engine which hosts it goes down temporarily, the state will be there as soon as it restarts.
The pico state is held and managed by the rulesets installed in it. Each ruleset can hold a portion of the entire state, and since there is no limit to the number of installed rulesets, the total quantity of data is also not limited.
Picos are persistent objects living on the Internet. They also can do computation. However, they work best when a limited amount of computation is required to react to each event, and to respond to queries.
Most web applications fit this pattern well. They need persistent state, including sessions. They need to be on the Internet and readily available. They need to respond and react very quickly to actions taken by the persons using them.
