Wafl 25 issue 65

[fawadasaurus]

addresses #65

[pinkforest]

Why not change this to url in String here as:
https://github.com/wasmflow/wasmflow/blob/main/crates/bins/wafl/src/commands/rpc/invoke.rs#L56

Seems to be hardcoded to http for some reason

String url gets into() Uri anyways from String in the end that gets passed to tonic and could avoid format!()

If the plan is to avoid certain Url schemes then there can be always assert!() and Error back

[fawadasaurus]

Why not change this to url in String here as: https://github.com/wasmflow/wasmflow/blob/main/crates/bins/wafl/src/commands/rpc/invoke.rs#L56

Seems to be hardcoded to http for some reason

String url gets into() Uri anyways from String in the end that gets passed to tonic and could avoid format!()

If the plan is to avoid certain Url schemes then there can be always assert!() and Error back

This is an interesting comment. For me, part of wasmflow is to simplify (abstract away) these decisions from the developer so that wasmflow can evolve without breaking people's code. Part of the philosophy behind making Wasmflow was that developer already have too many choices in the implementation details and instead should just be able to focus on delivering value with fewer decisions.

Yes, today the RPC call may be using HTTP but in the future it would be possible to switch to RPC over NATS or other type of event queue. Maybe even a web socket or some type of persistent connection mechanism could be used. In the future, there could perhaps be a performance based best alternative or fall-back capabilities to use different protocols.

[pinkforest]

Most protocols that are worthwhile today take url based endpoint and as a developer I just want to throw url in without having to figure out command line options - throwing url at something makes me not need make decisions how to pass things to separate CLI arguments - URLs often also carry other information in parameters.

You can always in the future add further CLI options for protocols that require different scheme but URL should be the default that covers the most.

Most MQs including nats have URL scheme: https://docs.nats.io/using-nats/developer/connecting

Even WebSockets are modelled as ws[s]:// and mqtt mqtt[s]:// as well etc ..

And yes URL as a tried and trusted standardised scheme supports multiple protocols, encryption / authentication options, connection options as well as other supplied often proprietary protocol / application specific arguments at ease

[fawadasaurus]

Ok. I am going to make this a new issue because we also want to make sure this is consistent with wasmflow binary and manifest and introduces no issues end to end.

[jsoverson]

LGTM. We do need to fix the argument to make it a connection string, but we'll have to do that across the config and all the binaries to keep everything in sync. Tracking in #67