HTML doesn't let you annotate a file, it requires you to modify it.
I propose instead to put markup in 1 or more layers separate from the underlying text (or video, or audio, etc.). It's a simple matter to split HTML into these layers, each byte inbound is part of an HTML tag, or the underlying source to be marked up.
As each tag comes it, the source byte count is recorded as the start, and length is set to 0 When the tag closes, length = (source byte count - start)
Separating the tags from the source solves a lot of navigation issues. Any modifications to the plaintext could be saved as operational transforms, thus all markup layers could have those same transforms applied in a straightforward manner.
Layers of markup could be turned on and off, or even have an value analogous to Opacity applied to them.
Layers could composed of multiple sources as well, allowing for transclusion and many of the other ideas from Ted Nelson's Xanadu.
My goal in the end is to be able to compose documents which draw from many sources, into a view (or set of views) that helps convey complex ideas with a rich context without the need to create a forest of HTML pages. I want to fulfil the vision of the Memex laid out by Bush in 1945.
After that, then we get to apply this idea to source code, and things get really interesting.
---
On the back burner, is MSTOICAL, my fork of STOICAL, which is a fork of STOIC, a forth dialect that supports types and type checking in a manner much unlike Fig-Forth. (I'm not a C programmer, and there's a lot of code to review, I'm thinking the first project will help annotate the second)
In the Cloud, monitoring and supervision is all about metric collection and analysis. The good old days of alerting (with tools like Nagios, Icinga, Zabbix, ...) seems to have been forgotten.
IMHO, numbers (metrics) are good for machines, not humans. Alerts provide a very simple way of detecting what's wrong. This is why CI/CD tools have a "Green/Red" status for their pipelines (hello Jenkins, Github Actions, Gitlab CI, ...) and you could build "weather dashboard"[1] representing the current state of your infrastructure.
I (and many coworkers at the time) found that scaling a Nagios or equivalent is unnecessarily hard/complicated. You basically have to maintain 2 infrastructures, your production and your monitoring. It takes time and energy.
Kubirds is a solution for this. It is a Kubernetes Operator, built upon TektonCD[2], so your monitoring will scale along your Kubernetes Cluster. It provides alerting with 4 states (success, failure, regression, fixed) and notifications in a Plug'N'Play way. You put your supervision workload in Docker images, write some simple Kubernetes resources and voila! Your supervision is up and running.
This implies that supervision can (and is) more than just monitoring. Everything that must be run periodically and whose status is something you care about, is a supervision workload.
We are currently using it to run our monitoring infrastructure, and to build a trading bot (not for crypto) with a partner. And possibly other use cases in the future[3].
[0] - https://kubirds.com
[1] - https://kubirds.com/img/screenshots/dashboard-weather.png
[2] - https://tekton.dev
Why I think it's cool? I think NLP is cool. I like language.