Filename format

[RichardCrawshaw]

The filename format is defined to be <module name>-<module identity>-<version>.json However, there are module names that include a hyphen; for example CANBIP-OUT-A535-5b.json. This makes interpreting these filenames more challenging that it ought to be. Could the format either:

• Include the specification that the module name not include a hyphen; or
• Change the separator character to an underscore (and specify that the module name not include an underscore); or
• Be changed in some other way that encompasses the above requirements.

[david284]

I can't enforce what is used in module names unfortunately, the allocation of module names for 'registered' modules is done by others, and it could be any character And for 'unregistered' modules it's up to the developer (We have to hope that any characters used are valid in filenames - but whoever creates a module file will find that out pretty quickly)

So a different separator character could potentially still end up in a module name But the characteristics of the filename format is that the last two segments are fixed format So I would recommend going 'backwards' from the end of the filename to always provide the correct result Yes, it's a bit more effort, but avoids having any extra constraint on naming

I've probably been a bit remiss in not mentioning this in the document - so thanks for raising the issue

[RichardCrawshaw]

Yes, fair point.

How I've worked around it is if there are more elements than expected, after doing string.split then concatenating the first two separated with '-' until there are the right number.

Happy for there to be a documentation fix explaining what you've said above.

[SvenRosvall]

Richard, do you need to interpret the existing file names? Isn't it easier to lookup the files you need based on the module types you are working with on the bus or with stored configurations. If you look at it this way you construct a file name based on the module name, manufacturer, module id and version. Then you check if such a file exists. For the case where you don't have the module name (in CBUS you can only get it while in setup mode) you can just search for a file pattern that matches manufacturer, module id and version. Hopefully this works with how you work with the descriptor files.

[RichardCrawshaw]

It is absolutely necessary to interpret the module file names. They are the only definitive source of module ID, and version. Critically the ID and version are not included in the file format, and the name often differs between the filename and the name field in the JSON. The JSON can be missing the 'CAN' prefix, or have suffix characters, or be completely different! Being able to load a set of modules up front rather than on-the-fly is also necessary. Users will want to see the list of the installed module information, including version, regardless of whether that particular module is physically connected. Being able to interact with the module UI without needing the physical module present, or even having a connection to the CAN bus is also a requirement.

[david284]

The CAN prefix is an interesting topic - the 'registered' module names typically have the CAN prefix, but the NAME command returns a name without the CAN prefix (I can see why, to reduce the character count so it fits in a single message) It's also worth mentioning that the NAME command only works in 'setup' mode, so unavailable in normal operation, so not that useful The common 'human' usage is to use the name with the CAN prefix, hence starting the module filename with that, so it's easier to find for us mere humans Strictly speaking it's not necessary, as the manufacturer & module ID uniquely identifies the module, but that's not very 'human readable' if browsing a directory of files

[RichardCrawshaw]

Whether the CAN prefix is used or not isn't that important. The important thing is consistency. Either all should, or all shouldn't. However, since it is possible to give a module a name that does not have the prefix, I would suggest that including it would be more sensible.