# 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.
