I do -- https://github.com/apache/openwhisk-runtime-dotnet/issues/34 - The commends below are based on the code @kamyker pointed out in https://github.com/kamyker/openwhisk-dotnet-csharp/commit/f9a739779887b4262c987c0be8bf2b77071c651b#diff-6bc49d26f451cad6d8312deca5a0eadeL89-L96. Comments are for everything in the diff, not just the extraction aspect of things as mentioned in his comments. - Things to avoid (I think at least, please provide comments): + The overall diff will essentially break the existing contract and introduce a method not used in any other runtimes (AFAIK, I haven't looked at other recently). + Right now, we pass a JObject (essentially a class that exposes the payload as a JSON object, it is from the Newtonsoft.JSON library, which in the .NET world is the most used library for JSON serialization and manipulation [That's why I picked it for handling JSON in the runtime]) + This change will remove that and essentially pass thru the HttpRequest object (the originating object going into calling the function -- this is where I don't think we have any other runtimes doing this) - Things to look into a bit (since the change is more than just extracting a zip): +@kamyker explicitly handles the steps of extracting the payload and that might be faster than the helper method provided by the .NET runtime https://github.com/apache/openwhisk-runtime-dotnet/issues/39 - I believe this is resolved with the latest code in GitHub, but I am not sure if it has been included in a release. https://github.com/apache/openwhisk-runtime-dotnet/issues/35 - I believe this is also resolved with a change to validating the payload size and allowing larger zip files based on configuration. If I recall, this is in the latest release. In regards to the .NET serialization library used, backwards capability always comes to mind. Changing the library used also changes the object passed between our runtime and the end user function. We might be able to implement some code at Initialization that analyzes the end user function to see what object type the function expects and route it to a Newtonsoft.JSON handler or another libraries (maybe the one included with .NET now, it's gotten a lot better) handler and make a recommendation to migrate to the new handler and eventually phase out the Newtonsoft.JSON one. Just a thought on how we can handle changing that -- which is another thing @kamyker pointed out. Again, Newtonsoft.JSON was picked since it is the de facto standard for JSON in .NET. Thanks!!Shawn On Wednesday, December 16, 2020, 08:08:53 AM CST, Rodric Rabbah <rod...@gmail.com> wrote: Deprecating 2.2 makes sense to me being out of support. I'm neutral on 5.0 vs waiting for .NET 6.0 (I am not a .NET developer though :).
There were a couple of issues in the repo about improving the performance of the .NET runtime by reducing dependencies and tweaking the JSON serdes. Do you have thoughts on those? -r On Wed, Dec 16, 2020 at 12:02 AM Shawn Black <endo...@yahoo.com.invalid> wrote: > Howdy, all! > > I wanted to get some feedback on the current state of .NET within the > OpenWhisk ecosystem. > > Right now, we support .NET Core 2.2 (not LTS and no longer supported) > and .NET Core 3.1 (LTS). > > .NET 5.0 was recently released, but I would like to skip supporting this > version as it is not an LTS release. > > I think it would make more sense to wait for .NET 6.0, which will be an > LTS release. > > Once that is out, we can add support for it and then deprecate .NET 2.2. > > The .NET Core 3.1 runtime supports running .NET Core 2.2 binaries (we > have a unit test to support this). > > Thoughts? Concerns? > > Thanks!! > > Shawn > >
