The biggest reason was we wanted a system that guaranteed capturing one sample per loop of code execution, at a well-defined point in the code execution. From what I understand, when interacting over network tables, the behavior is more asynchronous. I think that if you had an asynchronous producer/consumer model like that, the producer would need to source a queue of data to meet the requirement… which, to my knowledge, isn’t part of the current network tables implementation.
Additionally, there’s some technical inertia - we started developing these systems back in 2016, as workarounds to the limitations of Smartdashboard. They kept working, and people know how to use them, so there’s resistance to “change for the sake of change” during the build season. Evaluating other options hasn’t risen high enough on anyone’s summer to-do list to actually force the change.
I’ve looked into other database formats in the past, but nothing beat the ease of implementation of CSV (Since, largely, we weren’t 100% satisfied with any of the off-the-shelf offerings for tools, and knew we’d be at least partially implementing things ourselves). In a broader sense, our goal is really to emulate parts of the functionality present in ATI’s Vision or Vector’s Canape suite of tools, which can drive some subtle differences from more CS-y data visualizations.
Totally not to say we’ve picked the best option. Technical inertia is a very real thing.