RFC: Use URIs for transport selection and config

[M1cha]

I implemented the UDP transport and realized, that I can't simply add a --port argument, because that's already used for the path to a serial port.

Also, with the current way, the more arguments we add, the harder it gets to detect what the user wants to do, which is related to this comment in the code:

# TODO: type of transport is inferred from the argument given (--port, --ble, --usb, etc), but
# it must be the case that only one is provided.

So I propose to have a single argument --transport, which accepts a URI:

• serial:///dev/ttyACM0?baudrate=115200&rtscts=1
• ble://[aa:bb:cc:dd:ee:ff]
• udp://127.0.0.1:1234
• udp://[::1]:1234

And this could actually be implemented by smpclient, rather than smpmgr, so smpclient doesn't even need any knowledge about the transport anymore.

Let me know your thoughts.

[JPHutchins]

Hi @M1cha, thanks for digging into this! I think that this could work. However, I hate strings 🤣, and I'm already planning on a breaking change to the smpmgr interface where the transport is a required positional argument:

smpmgr ble ...
smpmgr uart ...
smpmgr usb ...
smpmgr udp ...
smpmgr can ...
etc...

It is to allow each transport to define a unique interface for address and other connection parameters. And for each transport to implement scan.

This involves correcting a design flaw that you'd identified in smpclient. The SMPClient should not own the address, the SMPTransport should own the address. This became evident in the UDP implementation where there is an address + port (currently ignored).

Summary: breaking changes in smpclient and smpmgr are required to successfully move on to the next phase - I'll tag you on relevant issues.

[M1cha]

However, I hate strings 🤣, and I'm already planning on a breaking change to the smpmgr interface where the transport is a required positional argument:

I get that, I mean you can parse strings into types, but doing that on URIs probably wouldn't nicely integrate into typer.

smpmgr ble ...
smpmgr uart ...
smpmgr usb ...
smpmgr udp ...
smpmgr can ...
etc...

That may conceptionally be a little bit weird, because now you have the same generic functionality in all subcommands (image upload etc). I know it's probably easy from the code-side, I'm mostly talking about the CLI interface.

smpmgr will probably never have this issue but I wonder how this could be solved if there were two things where you can select an implementation and pass parameters to it. Your subcommand design wouldn't allow for that unless you would allow chaining subcommands 🙈

That being said, this subcommand-design should solve all the issues and will probably work really well. I also can't think of a better typesafe way to do this.