Part 3 of 6 Watching and steering in a browser
Your work in your calendar
By the end of this chapter, the website rebuild's deadlines are in Keanu's calendar application, beside the rest of his week, and they keep themselves up to date.
This is the way in that is not really a way in. Nothing is installed, nothing signs in, and nothing comes back: a deadline filed at a terminal turns up in your diary, and that is all it does.
The work so far
Laurence's instance is serving at https://tasks.example.com with the website rebuild filed in it, and Keanu reaches it from his own machine, as Your terminal here, your work there set up:
uv tool install subroutine
subroutine init --workspace metacortex --instance-name MetaCortex
printf 'public_url = "https://tasks.example.com"\n' >> ~/.config/subroutine/config.tomlsubroutine serve
subroutine project create web "Website rebuild"
subroutine add "Rewrite the home page copy by Friday +web"
subroutine add "Choose a typeface for the headings by Tuesday +web"
subroutine user create keanu --name "Keanu Reeves" --workspace metacortex
subroutine token create --username keanu --title "Keanu's desktop" | tee /tmp/for-keanu
uv tool install subroutine
subroutine init
token=$(grep -o 'sr_[A-Za-z0-9_-]*' /tmp/for-keanu | tail -1)
echo "$token" | subroutine connections add work --url https://tasks.example.com
subroutine use work/metacortex
Make the subscription
One command, and you need a terminal only for this:
feed=$(subroutine calendar create "The website rebuild" --project web | grep -o 'https://[^ ]*')subroutine calendar create prints one address, ending .ics, and prints it once. Paste that into whatever you keep your diary in, under whatever it calls subscribe to a calendar or add by URL. From then on it updates on its own and you never touch it again.
The line above keeps the address in a shell variable rather than printing it, so that the rest of this chapter can use it without putting it anywhere it should not be. Which is the first thing to know about it.
The address is a password
Anybody who has that address can read everything the feed shows, for as long as it works, and nobody at the instance can tell that they are: a fetch from somewhere unexpected looks exactly like one from your phone. So it goes into the calendar application and nowhere else.
It is shown once. Nothing recovers it afterwards, the instance included, which keeps only a fingerprint of it. Lose it before you have subscribed and you reset the feed for a new one.
subroutine calendar list shows what you have, without the addresses:
subroutine calendar list
What arrives
A calendar application fetches that address every so often and draws what it gets. Here is the same fetch, sorted, because a feed puts its events in no particular order and a calendar sorts them by date anyway:
curl -s "$feed" | grep '^SUMMARY' | sort
curl -s "$feed" | grep -A 1 'Rewrite the home page copy'
What shows up is an item's start, an item's deadline, and both where it has both: the day you meant to do it and the day it is due are different facts, so a feed showing one would hide the other. A deadline reads Due: <title>. Something that repeats on a fixed schedule arrives as a repeating event, so your calendar draws the series rather than the instance sending hundreds of copies of it.
A week of the recent past, and about a year ahead. The past is kept on purpose: most calendar applications drop an event the moment a feed stops sending it, so leaving finished work out would erase it from your calendar's history the moment you ticked it off.
It shows what you can see, asked afresh every time. Losing access to a project takes it out of the feed that day, and there is no way to make a feed of somebody else's work.
Nothing comes back
Moving an event in your calendar changes nothing here, and deleting one there completes nothing. The feed is a copy, kept up to date, and the work still lives in Subroutine. That is the trade for it working in every calendar application without an account, a plugin or a sign-in.
If the address gets out
Give the subscription a new address, which stops the old one that instant:
subscription=$(subroutine calendar list | awk '/The website rebuild/ {print $1}')
subroutine calendar reset "$subscription"
The first column of calendar list is that reference, which you would copy by eye; the line above picks it out so that this page need not. The subscription keeps its name and what it covers; you paste the new address into your calendar and carry on. The old one is no longer anything:
curl -so /dev/null -w '%{http_code}\n' "$feed"
subroutine calendar revoke stops one for good instead.
Narrowing it
A whole workspace is usually more than you want in your diary. Three ways to cut it down, and they combine:
Not checked: the build does not run this.
subroutine calendar create "Just mine" --mine
subroutine calendar create "Deadlines" --type bug --type feature
subroutine calendar create "This quarter" --project web --expires now+90d--project takes everything filed under that project too, --mine shows only what is assigned to you, and --expires stops a feed working on a day you name, which is worth setting for anything temporary.
If it will not make one
A credential that has been narrowed cannot mint a feed, and says so: A bounded credential cannot mint a calendar feed. A feed is read with its owner's whole sight, so one made from a token confined to a project could show more than that token can, and Subroutine refuses rather than deciding which. Ask for a credential that is not narrowed, or ask whoever runs the instance to make the feed.
If it says it has no address to give you, the instance has not been told its own. Ask whoever runs it to set public_url, then reset the feed: it is not broken, it simply cannot say where it lives. And if the command is refused outright, feeds may be turned off on that instance, which is its operator's decision to make.