[Jaci]

Thanks for the reply, you raise good points.

For the smart dashboard implementation, I agree that the constant updating of data would be superfluous, however, I believe that this limit should be placed on the Dashboard itself instead of the NetworkTables instance, which would keep teams from spamming the pipeline as well as allowing them to send data as they need to.

I'm aware of teams using their own Communication Code, as I did the same thing this 2015 season. Sure, it solves some of the inefficiencies of NetworkTables, but the point I'm trying to make is you shouldn't have to write your own Comms code to make it efficient, if FRC wants to set a good example for coding, they should practice what they preach. Efficiency and Simplicity aren't mutually exclusive.

Furthermore, I'd like to see the codebase for NetworkTables cut down. 62 source files is a fair amount for the JVM to load (for Java teams, esp on the small amount of ram on the RIO), but you stating that there is a C++ library backend makes me hopeful this won't be as much of an issue in the future.

Thanks for pointing that out about the control code, I admit that in retrospect I made a mistake regarding control code in my article.