Changes wasm middleware and output binding config to url instead of path

[codefromthecrypt]

Description

This switches the wasm middleware and output binding config to use url instead of path to read the WebAssembly module. This allows us to later implement HTTP and OCI.

Note: The output binding passes STDIN as well as arguments. This means it can run intepreters such as python. I will be implementing this with the OCI scheme, tested with https://github.com/orgs/vmware-labs/packages/container/package/python-wasm

Issue reference

related to, but won't close #2700

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
  • WASM output binding content docs#3358 (output binding)
  • wasm middleware: change path property to url docs#3359 (middleware)

Build failure

[yaron2]

Thanks, LGTM overall. See lint failure.

[codefromthecrypt]

thanks for the look. lint fixed now!

[codefromthecrypt]

@yaron2 @salaboy I noticed 1.11 cutoff is tomorrow, so made a decision to just normalize the config property to "url" for both wasm middleware and the output binding and not implement HTTP, yet. Basically, this is ready to implement "http://" "https://" and "oci://" schemes.

middleware:

• wasm middleware: change path property to url docs#3359 updates the current docs
• component http wasm: adjust for config drift samples#150 updates the sample

output binding:

• we need to merge this, so that I can update dapr/dapr go.mod and actually wire it up. There's WASM output binding content docs#3358 to document, but that doesn't make sense until it is integrated. I can do this as soon as first thing tomorrow asia time, depending on when this lands.

[yaron2]

Is this a breaking change in terms of the path -> URL change?

[codefromthecrypt]

Is this a breaking change in terms of the path -> URL change?

yes, it is unless we want to back port the old one. As it is an alpha component and we broke it before not sure the rules.

[codefromthecrypt]

ps I was wrong, it looks like the wasm binding was already integrated in dapr/dapr#6269 so the only thing left is docs and just updating components-contrib version in dapr/dapr after merge

[yaron2]

Is this a breaking change in terms of the path -> URL change?

yes, it is unless we want to back port the old one. As it is an alpha component and we broke it before not sure the rules.

We can technically break the spec as this is an Alpha component, but where possible we try to provide backward compatibility. For this early component I don't think it's required.

Have you tested the middleware locally with Dapr after these changes?

[codefromthecrypt]

@yaron2 thx for understanding. I hadn't noticed a lot of use of middleware, so gut feel was to change the url before it becomes permanent confusion. I'll try middleware with a local build now and report back.

p.s. dapr/docs#3362 for the docs on components.

[codefromthecrypt]

@yaron2 tested and captured output here

[codefromthecrypt]

I added a commit to simplify the wasm output binding invocation, as well tighten the benchmark. We no longer return exit code zero on success (since 1.0)

[berndverst]

@yaron2 @salaboy I noticed 1.11 cutoff is tomorrow

@codefromthecrypt keep in mind the following deadlines in the future:

1. Feature Freeze -- any significant features should have complete PRs opened before this date (does not necessarily apply to this PR).
2. Code Freeze -- PRs need to have been fully reviewed and merged by this date. This is not the date for opening new PRs. It's best to allow 1-2 weeks before code freeze to give maintainers time to provide feedback and time for you to respond to feedback etc.

Of course we'll try to get this PR reviewed and merged -- but do keep these dates in mind in the future to make things easier for us maintainers. Thanks for your understanding.

[codefromthecrypt]

@berndverst absolutely will bear in mind dates.. in fact I would have prioritized differently if I knew them. Where generally do I find these as I found out by accident of asking nervously.

[berndverst]

@berndverst absolutely will bear in mind dates.. in fact I would have prioritized differently if I knew them. Where generally do I find these as I found out by accident of asking nervously.

We always create an issue in dapr/dapr that we also pin in the issues list there called "[version] Release Planning", for example "v1.11 Release Planning" dapr/dapr#5966

That's where we keep the timeline up to date and also discuss the major features we are including in that release.

Soon after we ship v1.11 we will create another such issue and pin it - so you can look for the "v1.12 Release Planning" issue then. The issue will be kept up to date with timelines.