Extend the SNIP struct to include Node's networking configuration

[TrainzLuvr]

For the sake of better UX/UI, user should be able to identify each node by its network topography. This would help in many cases such as troubleshooting, understanding network segmentation, and others.

Simple solution would be to increase the number of characters in the model-name to allow inclusion of keywords such as WiFi, CAN, Hub, etc. at the end.

Another, I believe a better solution, could be an additional 1 byte parameter inside the SNIP struct, whose bits identify Node's networking configuration (predefined words: CAN, WiFi, Hub,...and extensible in the future - unset bits are reserved) also allowing for multiple bits to be set.

E.g. model-name would contain: South-East Junction Yard (WiFi) Eugene West CP (CAN)

[balazsracz]

The SNIP structure is defined by the standard: the fields, their meaning, and their length are all set.

You will need to come up with shorter model names :)

Note that in the JMRI UI we typically identify nodes by their user name and description fields which can go to 64 bytes length.

[TrainzLuvr]

So the SNIP standard could not be amended to include for example Networking, beside Hardware and Software fields?

I suppose one could add these networking definitions into the name, I just think that's a band-aid solution. :)

If a new field is added JMRI could for example sort and group Nodes by network topology using that field. Right now that's not doable and some layouts could have many many nodes. It's one of those "forward looking" features that might not seem important now, but would in the future.

[balazsracz]

If you want to change the standard, this is the process:

• you have to create the new draft standard text and TN
• propose it to the group
• show two (preferably independent) implementation that the new proposal works
• then we can adopt it.

I do not however think that your use-case is valid (i.e. the problem to exist) and neither that your proposal would solve the problem that you are proposing to exist.

A typical user is not a techie and they couldn't care less how a board is connecting to the network once it is connected and working. We should not overwhelm a typical user with information they don't care about. If the node is not working, we won't see the SNIP report from it so at that point it won't be of any help. The SNIP standard is transport independent and I would like to keep it that way. The topology of the network is a lot more complicated than CAN or WiFi and your suggestion does not help recovering that. Having a protocol and a standard for recovering the actual topology would be interesting as a debug tool. The topology is defined by segments and links; some broadcast (CAN), some pointopoint (TCP) mostly with hubs. There can be multiple hops between nodes and unicast links joining broadcast segments, possibly yielding complicated topologies.

I have seen a user with 120 nodes and here is what they care about: which part of their layout is that node operating on. So they prefix the node user names with the layout area (town/junction) names, and use the sort by user name function. This allows them to easily locate the board they are trying to work with in the list. Modular clubs would probably prefix by owner name then module name.

[TrainzLuvr]

Fair enough and thanks for the feedback. I admit I sometimes think first as a techie and then a model railroader, so ideas would come from that angle, and not necessarily what everyone would want. I'll close this now.