Thanks for the detailed explanations Shawn! -r
On Wed, Dec 16, 2020 at 10:48 AM Shawn Black <endo...@yahoo.com.invalid> wrote: > 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 > > > > >
