finished the hub's logic, half done with the interfaces, and hopefully working on pi logic soon

devlog/2025-06-05-Much-progress.md

@@ -0,0 +1,71 @@
+# Reworking Almost Done
+Date: 2025-06-05
+
+## Goals and expectations
+Build the framework for the entire fabric's logic.
+
+## Results
+Nicely done.
+
+This should've been split into several commits, but it's still work on
+the same project.  The following is all that's been done:
+
+1. Completed the hub's logic.
+2. Began reworking the interfaces' logic, already done with the RX
+   side of things (the RX side always seem simpler).
+3. Built my own `git` server using `gitea` and `nginx` to host my
+   stuff (ROSE included).
+4. Removed `specifications.md` and revised `protocol.md` to keep them
+   updated with the reworked routing logic.
+
+## Is KISS elegance?
+> Keep It Simple, Stupid.
+Is this elegance?
+
+It could be, when everything else is working within strict bounds
+(e.g. the hub's strict logic), leveraging that strictness to simplify
+some logic (e.g. adding a cooldown period for queue slot allocation)
+is elegance.  Leveraging the strictness allows the logic to be
+simplified, and the simplicity is elegance in its most natural form.
+
+## Reflections
+1. KISS.  Letting the interfaces manage the packet addresses was a
+   great decision.  It dumbed down the hub's logic at the cost of
+   adding a bit of complexity to the interfaces' logic.  This would
+   also make things do one thing and do that thing well.
+2. Be organized.  Organize the components by their functionalities.
+   It would prove to be very useful when there's a dozen latches
+   coming in and out of the interfaces/hub and you'd like to know if
+   you missed something.
+3. Get sidetracked, absorb outside stimulation.  Even though my last
+   devlog said to focus, there's still the need to know how other
+   things operate, even if they may seem irrelevant.  I remember
+   reading the code for `SMaRTT-REPS` and `STrack` and some new CC
+   algorithms for UET during my time at Huawei, and then reading one
+   of their proprietary CC algorithms, which had a much simpler logic
+   but performs similar to the above-mentioned more complex ones.
+   Getting sidetracked would help you think - is there a simpler way
+   to achieve what I want?
+4. Get started.  I think I might stress this every time two commits
+   happen days away from each other, but I can never stress this
+   enough.  I spent hours deciding whether or not to start coding with
+   the time I have on hand, but the real action only took a fraction
+   of that time.  Begin, progress is progress, no matter how much it
+   is.
+
+## Final thoughts
+There are a lot of ideas that are still "under validation" in my mind,
+like for example implementing a dual-issue round-robin scheme for the
+hub to increase the maximum throughput and prepare ROSE for scale.
+They don't go unnoticed, I'd add them to the devlog and hoping that
+someday when I get the leisure to return to them, I can implement
+them.
+
+Also, finding time for ROSE has been hard, only fragments of time has
+been found on most days.  But there's no say that I can't do something
+with that time.
+
+## Next steps
+Complete the TX logic, figure out the byte syncing for the SPI side of
+things, and also test the things out on a TB and hopefully start
+making my way back to C land on RPi's.