Quote:
Originally Posted by Greg McKaskle
While there is absolutely nothing wrong with doing your own communication, advising others against using network tables seems a little strong.
Network tables has now been vastly simplified, is based on TCP, and is used for a number of core features in the dashboards. What issues have you seen with it? What documentation did you hope to find?
Greg McKaskle
|
I'm sure the LabVIEW implementation of networkTables is excellent, but the Java implementation leaves a LOT to be desired.
Let's look in the API,
where we find this - 8 separate packages for NetworkTables2 and its component features.
Since there's no example code for Java NetworkTables2, or at least none that's easily findable, trying to figure out the code from the API seems the next logical step. Determining what acts as the client and what should act as the server, i.e. robot or dashboard, is not made any easier by the
client API page, which almost completely consists of the class names restated in English instead of any actual descriptions of what they do. As a fun aside, if you look at the methods inside the classes, a good amount of them don't even have any descriptions whatsoever. The server API page is the same.
As I'm said, I'm sure its use in the Dashboard is great, since it's all implemented in LabVIEW. The Java, however, has been all but neglected.
As for what documentation I'd like to see, example code would be nice, followed by actual complete documentation of the classes and methods in the APIs. None of the packages even have descriptions at all, few if any classes have meaningful descriptions, and the methods are the same.
If these issues are resolved, and NetworkTables is developed into a platform that Java programmers can actually easily implement and use, then I will gladly recommend it, as the concept behind it is excellent. Until then, writing one's own socket code is simply easier and more comprehensible.