NetworkTables needs to change.

[virtuald]

Originally Posted by fovea1959

Is there a strong possibility that pynetworktables2js will have appropriate changes made to keep working? I'm thinking about having the team move to that for dashboards....

I've been told that the new version of networktables will be backwards compatible with the old, so even if I did zero work, it would work.

However, I'm sure it'll get changes to take advantage of any new features.

[fovea1959]

Originally Posted by virtuald

I've been told that the new version of networktables will be backwards compatible with the old, so even if I did zero work, it would work.

However, I'm sure it'll get changes to take advantage of any new features.

from what I've seen so far, I'm not at all surprised at that.

any ideas of what's changing (what additional functionality we'll see)?

[Peter Johnson]

Originally Posted by fovea1959

from what I've seen so far, I'm not at all surprised at that.

any ideas of what's changing (what additional functionality we'll see)?

FYI, I'm the person rewriting/updating C++/Java NetworkTables for 2016. The short list of new features include: value persistence (basically improved preferences; network tables will save/load changed flagged values automatically to an .ini file on the server), server and client self-identification (so it's possible for the server to more easily figure out what clients are connected in a dynamic IP environment), entry deletion, remote procedure calls, server reboot detection, and "raw" values (distinct from strings). There have also been minor improvements made to the underlying wire protocol, such as changing the way string lengths are encoded. A full list can be found at https://github.com/PeterJohnson/ntco...rom-2-0-to-3-0. A couple of these features (namely RPC) have not yet been fully exposed to the Java/C++ "NetworkTable" class even though they're implemented in the core library, but I expect to finish adding them this fall.

One change that did not make it into the new protocol version was a broader protocol-level approach to improve synchronization on reconnect (namely the issue where you need to shut down every client and server to start "afresh"). We were discussing a number of ideas for this but ran out of time to make a change this year. I'm still mulling over whether there's a good approach to use server reboot detection to make a smarter decision here without doing something fancier at the protocol level.