Support defining variables and methods and fix some issues

[lizzzcai]

1. use mux as the default router to support defining variables (pass by context) and methods (not supported in cloudevent as other methods are disabled by default in the current implementation).
2. every function has its own function context in the multi-function use case (functioname -> function context), otherwise, the function will read the result of others
3. in openfunction function type, pass the userdata to the function if the request is a cloud event, which matches the behavior in async.
4. fix some small issues.

find example here

close #51

Signed-off-by: Lize Cai lize.cai@sap.com

[benjaminhuo]

@tpiperatgod do we need to w.Write(rm.FuncOut.GetData()) here?
we don't have this previously

[tpiperatgod]

need to refer to the mechanism of the ResponseWriter in the http package: https://pkg.go.dev/net/http#ResponseWriter

[benjaminhuo]

This is a big enhancement to current go ff.
Can we add more samples into the samples repo and docs to the openfunction.dev site?
@lizzzcai

[lizzzcai]

This is a big enhancement to current go ff. Can we add more samples into the samples repo and docs to the openfunction.dev site? @lizzzcai

Sure. I will add samples and update the docs in other PRs.

I will update the code with the above comments later.

For the function context, as multi user functions feature is only in knative runtime now which don't have input binding and pubsub. For the output bindings, we will leave it open for all the user functions so the user can access all the output binding in ctx.send(...).

However, for the plugins, I am not sure how to handle it now. As the plugin is in the framework level, it will apply to all user functions.
I can come up with two use cases,

1. metrics, tracing etc. Which is good to be in framework level and apply in all the user functions. (for example, skywalking)
2. pre and post processing of a user function. I think for this use case, it is not so necessary to use plugin, as I can do it in the user function as well by wrapping the function.

maybe we need to clearly define the usecase of the plugins.

cc @tpiperatgod

[benjaminhuo]

However, for the plugins, I am not sure how to handle it now. As the plugin is in the framework level, it will apply to all user functions. I can come up with two use cases,

1. metrics, tracing etc. Which is good to be in framework level and apply in all the user functions. (for example, skywalking)
2. pre and post processing of a user function. I think for this use case, it is not so necessary to use plugin, as I can do it in the user function as well by wrapping the function.

maybe we need to clearly define the usecase of the plugins.

We can use annotations in function's crd to provide additional context for plugins as we discussed in yesterday's meeting
And this can be added in another proposal and PR

[benjaminhuo]

Thanks for the PR!