Month: August 2021

What we lost (a paean, perhaps, to RSS)

Recently Dave Winer has been posting thoughts about using tags (some of us old-timers used to call them ‘topics’) in his blog. This is more than a little bit poignant because I have a history here, and Dave started it with Radio Userland and RSS.

Back in 2003, Paolo Valdemarin and I built a product called k-Collector which was an offshoot of a tool, liveTopics, that I had built for my Radio based blog “Curiouser and Curiouser” (the v1.0 of this one).

While the notion of categories was already a feature of blogs & RSS, liveTopics was I think a first in that it allowed a user to add topics to posts, to publish per-topic RSS feeds, and even to create a tagged index of posts. Thanks to the magic of the Wayback Machine you can still see this stuff, even though that blog is long gone.

Then k-Collector took this notion to the next level by connecting together the topic-based feeds of a community of blogs and creating a collective view, based on shared tags. We published a service W4 for a while. Again the magic of the Wayback Machine means you can still see it (the related topics still work and even the topic filters!)

To feed k-Collector we needed a way to transport tags through RSS. So Paolo and I invited Easy News Topics (ENT) as an RSS2.0 module to do the work. Whereas liveTopics only worked with Radio Userland, now anyone could play by simply putting their tags in their RSS feed.

k-Collector was too revolutionary for 2004. Companies did not routinely blog at that time, let alone see the value of their employee’s blogging about their experiences and challenges, didn’t see the value of connecting the dots. Sad that.

Today k-Collector would not be possible. That alternative future where everyone started blogging and putting their content in RSS2.0 feeds that we could analyse to connect those conversations did not happen.

Instead Facebook Workplace, Slack, and a host of other silo’s took hold of the future and, no matter what good they may have done, we’ve all lost out.

Libraries can start processes too!

It’s the kind of thing that, if you are used to other languages, would make you very suspicious. Library code starting its own processes — you can almost feel the mess and sense the bugs just musing over it. Yet in Elixir (and, of course, Erlang too), this is a totally normal thing to do.

The Elixir approach to shared mutable state is wrapping it in a process. In this case, I needed a counter and the easiest way to implement it is to use an Agent which is a kind of process designed to handle simple state. In this case, the get_and_update function allows me to return the counter and increment it as an atomic operation.

To start an Agent you use the Agent.start_link function. But where to call it? Do I have to add some equivalent initializer function to my library? While not exactly onerous it felt awkward somehow like my implementation was leaking into the caller. Then again did I have to stop the agent process somewhere? Where would I do that?

Now I figured out how to manage the life-cycle of the agent process myself within the library. But it turns out to be unnecessary. All I had to was make one change to my mix.exs file and one addition to a module in my library.

def application do
  [
    extra_applications: [:logger]
  ]
end

becomes:

def application do
  [
    extra_applications: [:logger],
    mod: {Ergo, []}
  ]
end

along with changing the referenced library module, Ergo to look like:

defmodule Ergo
  use Application

  def start(_type, _args) do
    Supervisor.start_link([Ergo.AgentModule], strategy: :one_for_one)
  end

  …
end

This is enough that any application using my library (called Ergo, btw) knows will automatically start the Agent and manage its life-cycle. Without me, or the calling application, needing to know anything about it at all.

This is a pretty neat trick.