25 · A feed with parameters

The feed was built for a reader’s app: a person pastes in the address, gets the entries, reads them outside the site. That recipient always wants the same thing — the latest entries, with full content, with addresses that lead somewhere. Then a second recipient appeared, one the feed knew nothing about: an automation reading the same file in order to send an entry on to social services.

The automation wants something else, and that is not a whim. On its first run it needs the whole archive to know what has already gone out; a reader’s app is content with the last twenty items. It needs the image in the shape the destination service accepts; the app cares about the one that looks right in a preview. And it needs an address by which you can tell where a reader came from; for a person reading in an app such an address only clutters the location bar.

The answer is three parameters in the feed address: the length of the list, a source marker and an image variant. The bare address without parameters stays exactly as it was — that is a hard rule, because automations are already running against it, and changing the default behaviour would rewrite history for everyone using it.

The marker and the variant are tempting to merge: if an image service is reading the feed, surely we know what files it wants. But they are two different things. The marker says WHO is reading, the variant says WHICH file they need. Usually they travel together, not always — two services can want the same frame under different markers, and one service two frames in two scenarios. Merged once, they come apart painfully later.

One decision in this construction matters more than the rest and is the least obvious: the source marker is appended to the entry’s address, but the item’s identifier stays clean. Automations use it to recognise what they have already sent. If the identifier changed along with the marker, every switch of source would make the entire archive look new — and go out a second time. One added parameter can send a hundred notifications that way.

So the feed stopped being a view and became an interface. A view has one form for everyone; an interface has parameters, defaults and an undertaking that they will not change under those already using it.