Summary
Picos are a programming model for building decentralized applications that provide significant benefits in the form of abstractions that reduce programmer effort. Here are ten eleven reasons you should use picos for your next decentralized application.
...
Picos are persistent compute objects. Persistence is a core feature that distinguishes picos from other programming models. Picos exhibit persistence in three ways:
...
Picos provide a better model for building the Internet of Things. Picos are an antedote to the CompuServe of Things because they provide a scalable, decentralized model for connecting everything. We built a connected car platform called Fuse to prove this model works (read more about Fuse). Picos are a natural building block for the self-sovereign internet of things (SSIoT)and can easily model necessary IoT relationship. Picos create an IoT architecture that allows interoperable interactions between devices from different manufacturers.
Use Picos
If you’re intrigued and want to get started with picos, there’s a Quickstart along with a series of lessons. If you need help, contact me and we’ll get you added to the Picolabs Slack. We’d love to help you use picos for your next distributed application.
If you’re intrigued by the pico engine, the pico engine is an open source project licensed under a liberal MIT license. You can see current issues for the pico engine here. Details about contributing to the engine are in the repository’s README.
Notes
The caveat on this statement is that pico engines currently use URLs to identify channels used for inter-pico communication. Moving to a different engine could change the URLs that identify channels because the domain name of the engine changes. These changes can be automated. Future developments on the roadmap will reduce the use of domain names in the pico engine to make moving picos from engine to engine even easier.
Note that while rules within a ruleset are guaranteed to execute in the order they appear, rules selected from different rulesets for the same event offer no ordering guarantee. When ordering is necessary, this can be done using rule chaining, guard rules, and idempotence.
I first heard this expressed by Jonas Bonér in his Reactive Summit 2020 Keynote.