From the Benjamin Jowett translation of Plato’s Cratylus:
Socrates: Heracleitus is supposed to say that all things are in motion and nothing at rest; he compares them to the stream of a river, and says that you cannot go into the same water twice.
Heraclitus would have loved the web. The ever-changing river of information, flowing around and through us, brings his doctrine of flux vividly to life.
But I don’t think most of us truly embrace the doctrine of flux. We’re more comfortable with stocks than with flows. And that’s one of the key challenges I’m wrestling with at elmcity.cloudapp.net.
The service is not a database, and does not contain stocks of events. It is, instead, a hub that coordinates flows of events. But that model doesn’t make immediate sense to people.
Q: How do I put my events into your database?
A: You don’t. You just arrange for your database to publish a feed. The hub subscribes to your feed and to others, and in turn publishes a merged feed to a network of downstream subscribers. From the hub, or from anywhere in that network, people who find your events then follow links back to the authoritative source: You.
It’s a wonderful model, but a lousy elevator pitch. Given that most people are not computational thinkers, it relies too much on counter-intuitive principles: indirection, pub/sub, loose coupling. And it seems to be all about flux, which is psychologically challenging. Amidst all this dynamic flow, can’t we please have some constant anchor?
Actually we can. At the core of the service is a collection of feeds. The collection changes too, but much more slowly than the streams of events flowing through each feed. Feeds are relatively constant, and so they are manageable. For example, there are far too many events to make individual trust decisions about, but I can easily trust a feed or not.
Of course there are some ways in which we do need to manage individual items in feeds. For example, you can pluck an event from an iCalendar feed and stick it onto your personal calendar. Or you can transfer a single MP3 from an audio feed to your player. This feed/item duality makes the conceptual challenge of feeds even harder.
One new place to experience that duality is SpokenWord.org. My collection there is a mixture of feeds and items. Why items? Feeds are prospective. They look into the future for new items, and make them available to my podcatcher. But when I subscribe to a feed, I may want to make archival items available too. At SpokenWord I do that by “collecting” individual items.
In an interview with Phil Windley, SpokenWord’s founder and developer Doug Kaye says that he was surprised by the extent to which the service is being used to manage feeds rather than items. That’s true inbound, when people submit feed URLs rather than item URLs for inclusion in the catalog. And it’s also true outbound, when they use SpokenWord to consolidate many feeds into a single merged feed that’s more convenient to receive and manage in a podcatcher.
In different ways, the elmcity and SpokenWord projects are both encouraging and enabling people to think in terms of flows, and to manage feeds instead of items.
As we all become more adept at working with flows, I think we’ll need a richer vocabulary of patterns to describe them. At SpokenWord, for example, there’s a big difference between this feed and this one.
The first, based on a script I wrote, points to 45 chapters of Mark Twain’s Connecticut Yankee in King Arthur’s Court. It will never produce a new item. It’s just a way of packaging those chapters so a podcatcher can download them.
The second feed is The Moth Podcast, which is both a historical archive and a way to prospectively grab new items.
Neither pattern corresponds to an iCalendar feed, which is purely prospective. In calendar space I care about today’s events and future events, but almost never about the past.
In rivers of information, feeds provide one kind of anchor. Patterns that describe the nature of feeds, and our ways of using them, are another. These are sources of constancy amidst the flux.