"Nobody is deploying to production right now, right? Everyone's finished."
"It's not "deploying" if you're editing on the live server!"
Progress from last sunday at Chaostreff: We got our Erika 3004 type writer to type fast and error free by getting hardware flow control for its serial port to work. We tried first with a FT232RL-based USB-serial adapter, but it's flow control implementation is not fast enough: if the Erika signals "stop sending", it continues sending for up to 3 characters, which the Erika can't handle. But a Raspberry Pi can react fast enough if configured correctly, so now we can remove a bunch of pessimistic sleeps from the code.
I also worked on hooking it up as a terminal to other programs, so we hopefully can run text adventures or something on it for CCCamp.
Loads of space (this is only part of it) for our mini-IWC in Åmål! Sadly, not really the people to fill even a corner of it…
Not part of the main specification, but important for private feeds and worth documenting.
I see three models:
When the feed changes, the site triggers a notification to all subscribers. If the feed change is in a private post, it does not include it in the ping, either sending the last public state of the feed or an empty ping (effectively announcing an empty diff). Authorized subscribers would take this as a signal to fetch the feed with authorization attached.
This leaks the fact that *something* private happened to all subscribers. The hub is not involved in handling private information at all, and thus can safely be external.
The site could give different topic URLs (capability URLs) to private subscribers, and send matching notifications to them. (Compare how the WebSub spec recommends returning different
rel=self URLs for different content types. Potentially, fat pings could be used then.
A site could use an integrated hub for private subscribers and still let a public hub handle everyone else.
Compared to 1, it at keeps activity private and solves the issue mentioned above of subscribers potentially fetching needlessly. Compared to 3, it removes complexity, trust in the hub and leaking the cability URL is less problematic, but requires feed fetches on notification.
I think 2. is too much complexity. I think it makes sense to document 3., and potentially 1. as an easier option. Testing how it works with existing clients and hubs is needed.
lang=""support to this site. Default is
en, but posts can individually override this.