Almost two years ago, I blogged about using KRL to create a simple blog, called KBlog, based on something Ed Orcutt had done. The resulting code and concepts eventually became Chapter 12 in The Live Web. At first blush, building a blog in an evented programming language may seem like a mismatch between problem domain and technology, but it was delightfully instructive and, not as big a stretch as you might think.

In this post, I'd like to use the same motivating example, building a blog, to explore thinking about cloud-based persistent data objects, or PDOs. I wrote about PDOs and their relationship to KRL and personal clouds a few days ago.

A blog built from PDOs can be extremely decentralized. For example, we can make each blog entry a PDO. That means that the entries for a given blog could live on many different servers and still present themselves as a single blog. The servers hosting the PDOs can be geographically dispersed and owned by different entities.

An archive, representing all of the entries for a given month, is just a PDO with a connection to the PDOs representing the entries for that month. When I say "connection" note that I'm not talking about HTML links. I'm talking about full blown channels between PDO with the power to raise events, denote relationships, and so on. The blog homepage, is also a PDO with a set of connections that are changing over time as new entries are added to the blog.

Consider how searches work in this system. Searching the blog means sending a message to each entry with the parameters of the search and asking it whether it ought to be included in the results. A new PDO representing the results of the search is created and any blog entry that responds that it should be included is linked to the search results PDO. That PDO could be owned and controlled by the person doing the search, not the blog itself and hosted anywhere. The search results object would live as long as its owner found it useful.

Why draw the boundary at blog entries? Why not make each paragraph in each blog entry a PDO. I chose the blog entry as the boundary because it felt right, but the correct choice really depends on what you plan to do with the PDOs. Remember that each PDO is a stand alone virtual computer that can run code, store data, and has a unique identity. For blogging, the entry seems the basic building block. The choice, however, has consequences. If the PDO represents an entry, then we won't have a unique identity for each paragraph and won't be able to manipulate them independently. For example, in search, as I've described it above the results would be entire entries, not paragraphs because entries are PDOs and paragraphs aren't.

You might be wondering why we'd build a blog this way. The most obvious reason is that by giving each entry a separate existence, we allow it to be identified and manipulated independently. For example, imagine if every story at CNN was a PDO, you could "rip" a story off the page for your scrapbook of news stories. The story would be able to re-render itself to match the style of your scrapbook. Lucas, Ballay, and McManus point out in Trillions: Thriving in the Emerging Information Ecology that we can only do this right now with images due to an accidental association of a specific tag with a specific data object. If you drag a picture from a browser to your desktop you get a picture. That doesn't work for anything else—partly because the other links aren't independent objects that render intelligently based on context.

Entries in our blogging system, as we've mentioned, can live anywhere they find a compatible ecosystem. They need not be all on one machine because there's no need for them to be in the same database. In fact, they don't even need to be implemented in the same way, so long as they adhere to certain standards about how an entry is structured, what it means to be a blog entry (e.g. its API), and so on. There could be multiple copies of an entry for redundancy purposes.

Another feature of building the blog this way is that things like search results have an independent identity and existence. I can send you the search results (or a clone of them)—not as a bunch of text, or a query you rerun but as an actual object. You can manipulate it and interact with it. You can run programs on it.

Blogs, of course, are pretty simple things. More complicated things benefit commensurately. Imagine, for example, a PDO that represents your car. Links to your car's data via something like Carvoyent, it's manufacturer (for recalls, warranties, etc.), and your mechanic could ease the stress and burden of managing your vehicle.

A decentralized, PDO-based blog implementation probably isn't a new idea. Just new to me. Still, I think it's helpful in understanding how PDOs work and how they can be used to create decentralized systems that are functional.