Load Firmware currently requests a file path and server IP in separate fields. This assumes that TFTP will always be used.
Some switches support other methods like FTP, HTTP, HTTPS, SCP, local files already on the device, etc. It's unclear how these options would be mapped to the two inputs.
Currently I am ignoring the IP input and treating the path field as a URL.
If there were just a single input field, it could be used to support all cases.
The only cost is that the caller would become responsible for writing "tftp://".
Cases where something about the URL is not standardized (e.g. credentials) could be handled in a driver-specific way. The URL wouldn't necessarily be passed through directly to the device.
Load Firmware currently requests a file path and server IP in separate fields. This assumes that TFTP will always be used.
Some switches support other methods like FTP, HTTP, HTTPS, SCP, local files already on the device, etc. It's unclear how these options would be mapped to the two inputs.
Currently I am ignoring the IP input and treating the path field as a URL.
If there were just a single input field, it could be used to support all cases.
The only cost is that the caller would become responsible for writing "tftp://".
These could be passed in the single input field:
file.bin (for a local file already on the device) path/to/file.bin (for a fancier device) file:///path/to/file.bin (if we wanted to be uniform) tftp://123.45.67.89/path/to/file.bin in the input field. ftp://user:password@123.45.67.89/path/file.bin http://123.45.67.89/path/file.bin http://user:password@123.45.67.89/path/file.bin https://123.45.67.89/path/file.bin samba://user:password@123.45.67.89/path/file.bin
etc.
Cases where something about the URL is not standardized (e.g. credentials) could be handled in a driver-specific way. The URL wouldn't necessarily be passed through directly to the device.