[Discussion] MVC now serializes JSON with camel case names by default

In previous milestones, MVC's JSON serialization used Json.NET's default naming convention. This maintained C# property names in the JSON.
In 1.0.0, MVC uses camel case names by default. This matches most JSON naming conventions.
Potential compatibility breaks
Applications which depend on the exact bytes sent over the wire or that include code such as
dynamic d = JObject.Parse(body);

may need to be adjusted.
To restore previous naming strategy
If you have case-sensitive clients that cannot be easily updated, change your Startup from
    services.AddMvc();

to
    services
        .AddMvc()
        .AddJsonOptions(options => options.SerializerSettings.ContractResolver = new DefaultContractResolver());

Example
Before
public class Person
{
    public int Id { get; set; }

    public string FullName { get; set; }
}

Would serialize to
{"Id":9000,"FullName":"John Smith"}

After
The same model will serialize to
{"id":9000,"fullName":"John Smith"}

Note the initial lowercase letters.

This is the discussion issue for aspnet/Announcements#194.

See also the original issue we fixed in 1.0.0: #4283

What would this mean if we use a JavaScript framework like Knockout.js to map JSON inputs to view models in our client side code? And is there a way to change this back to Json.NET's default?

@clarkis117 , yes there is :
services.AddMvc().AddJsonOptions(options =>
            {
                options.SerializerSettings.ContractResolver = new DefaultContractResolver();
            });

I like this change, but -
I think it needs to be configurable to allow developers to choose the serialization naming convention to be used.

It's nice to let people choose
This change adds A LOT of work for me and others who will upgrade from RC1
Better backwards compatibility and upgrade path with existing custom libraries that utilized Json.NET

@brent-russell this is configurable ;)

@brent-russel, as @sandorfr showed, this is quite configurable. What exactly is missing from your perspective?

@sandorft @dougbu Oh, that's great!
Just communication and documentation then I guess. The announcement didn't hint at configuration at all. Most other announcements that introduce breaking changes provide instructions on how to implement or obtain pre-existing behavior.
Thanks!

hmmm ... I use typescript and tools like create intellisense file from web essentials to map automatically a csharp in the backend to a interface definition in the client.
If you use whatever tool to make automatically server-client entities in typescript, this way by default are not going to work

@lucamorelli Yes, this is one of the problems that I foresee running into with using Typescript tools like Typewriter. Potentially I'd have to change to change parts of my Typewriter model generation code to camel case, which would break significant portions of the manually written client side code.

I really don't  like this change,  it will effect thousand of developers. I suggestion  some feature like this:
[camelCase] // provide by json.net
public class Person
{
    public int Id { get; set; }

    public string FullName { get; set; }
}

this will give us more controllable of our code.
Json is not javascript, and it not only use by javascipt. It's a data formate now use in many languages,
Please rethink about it.

@John0King As shown above, this is already controllable. You can always revert to the old behavior if you prefer that, or go the explicit route and annotate the class with serialization attributes.
This change of the default behavior does make a lot of sense. Most other languages nowadays consistenly prefer camel casing for all members; it’s just C# that’s odd here with its pascal case properties. So languages consuming JSON are more likely to feel familar with camel cased JSON properties.
I welcome this change, thanks!

@John0King from my experience the Attribute thing is to be kept minimal, it's easily forgotten. The way to go is AddJsonOptions.
For the "I like this better", I personally don't care, but I think using AddJsonOptions should be a recommend practice not matter you want the default or another behavior.

Looks good to me. Saves having to set CamelCasePropertyNamesContractResolver in Web API.
Here is an example of doing this from the old Web API on the full .NET Framework, but I'm planning on porting this to Core after it RTMs.

Buggah...  Boh.
Anyways, I again find myself in the minority here.  I also believe I speak for a lot of the native/Xamarin/enterprise developers that wish to keep consistency between code (C#) and the data that represents that code.
I would feel better if this change default was hinged to a particular "style" setting/attribute somehow, meaning that in native/enterprise applications, PascalCase is the default, and in web applications camelCase is the default.

It basically is, though. It's literally one line of code to switch it
around.
On Jun 10, 2016 8:49 AM, "Mike-EEE"<EMAIL_ADDRESS>wrote:

Buggah...  Boh.
Anyways, I again find myself in the minority here. I also believe I speak
for a lot of the native/Xamarin/enterprise developers that wish to keep
consistency between code (C#) and the data that represents that code.
I would feel better if this change default was hinged to a particular
"style" setting/attribute somehow, meaning that in native/enterprise
applications, PascalCase is the default, and in web applications camelCase
is the default.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Mvc/issues/4842#issuecomment-225186624, or mute
the thread
https://github.com/notifications/unsubscribe/AAavtJZY3M0r8OFfYHyUPPNBLU0OeC8Sks5qKWtVgaJpZM4IyfXK
.

Yes indeed @ciel  I understand that, but what this decision says is that by default the camelCase is the better/preferred format, whereas PascalCase is not.  So what does this say about C#, upon which (ironically) the serializer is written in?
This introduces confusion and context-switching into the process.  I hope that you can understand my viewpoint and concern here.

I understand your standpoint and concern, and to an extent I share it. But
I also see the ease of switching makes it a non-issue overall. It could be
even further remedied by just including the code to control the format as
part of the default templates.
On Jun 10, 2016 8:54 AM, "Mike-EEE"<EMAIL_ADDRESS>wrote:

Yes indeed @ciel https://github.com/ciel I understand that, but what
this decision says is that by default the camelCase is the better/preferred
format, whereas PascalCase is not. So what does this say about C#, upon
which (ironically) the serializer is written in?
This introduces confusion and context-switching into the process. I hope
that you can understand my viewpoint and concern here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Mvc/issues/4842#issuecomment-225187992, or mute
the thread
https://github.com/notifications/unsubscribe/AAavtK-sPphSFo0gUngfnPV2Foy7oE8fks5qKWyegaJpZM4IyfXK
.

I don't think it is a good or wise decision. But, I also don't have my
fingers in dozens of projects. I have faith that the people who do made
this change for a good reason. That's all. I'm not discounting what you're
saying.
On Jun 10, 2016 8:56 AM, "Stacey Lynn"<EMAIL_ADDRESS>wrote:

I understand your standpoint and concern, and to an extent I share it. But
I also see the ease of switching makes it a non-issue overall. It could be
even further remedied by just including the code to control the format as
part of the default templates.
On Jun 10, 2016 8:54 AM, "Mike-EEE"<EMAIL_ADDRESS>wrote:

Yes indeed @ciel https://github.com/ciel I understand that, but what
this decision says is that by default the camelCase is the better/preferred
format, whereas PascalCase is not. So what does this say about C#, upon
which (ironically) the serializer is written in?
This introduces confusion and context-switching into the process. I hope
that you can understand my viewpoint and concern here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Mvc/issues/4842#issuecomment-225187992, or mute
the thread
https://github.com/notifications/unsubscribe/AAavtK-sPphSFo0gUngfnPV2Foy7oE8fks5qKWyegaJpZM4IyfXK
.

Also, the general naming convention for data names in json on the web now is snake_case, and not camelCase. Seems a little weird to set the default to be something that is in the middle of the c#'s naming convention, and the most common json naming convention.

That's all. I'm not discounting what you're saying.

Cool thank you for that @ciel. :)
And yes, I can see why it's a non-issue.  I mean, people say the same thing about xml vs. json. :wink:   To me it all comes down to consistency.  That is why I wonder if Xamarin/enterprise side of the aisle was consulted with this as this makes their (or our :smile: ) side inconsistent by default now.

Seems a little weird to set the default to be something that is in the middle of the c#'s naming convention, and the most common json naming convention

I hear you @0xdeafcafe (awesome name btw LOL!), but what we seems to get lost here is that there is a history and legacy -- not to mention an entire enterprise -- that you also have to consider here with MSFT.  This should be the learning lesson of project.json (as I tried to point this out back in the day, as well).
By itself, in the ".NET Core" or "web" way of things, this makes sense.  But when you shine this through the prism of MSFT's history and other commitments, you run into problems.
I think this just goes to further the need to recognize the schism/chasm that is within MSFT at present: enterprise (legacy/native) and web (new and shiny).  I don't want to infringe upon your standards (or creativity/innovation as what is going on here is great!), but let's not infringe upon others while we're at it.

@Mike-EEE I guess, I just don't get why they didn't leave it as is, and not annoy anyone (as we're all used to writing custom converts/setting attributes/custom serialization settings). Instead of changing it to something in the middle that is just going to irritate both sides, and only really please a few in the middle. Most "enterprise" companies either don't use JSON, or use PascalCase if they do.

You know @0xdeafcafe ... I actually just re-read what you wrote and have to say that I totally misunderstood you!  Yes, you are correct.  This does seem to be a "middle" ground play, for lack of a better word.
And the web evolves so fast, who knows what format will be the flavor of the month, next. :wink:

Most "enterprise" companies either don't use JSON, or use PascalCase if they do.

Very true!  We should say they don't use JSON... YET.  As .NET Core moves towards making this a requirement. :stuck_out_tongue: But I am very much a proponent of enabling developers and organizations to "bring your own serializer" and allow them to use the data formats (and corresponding tools) that make them the most productive.  A notion that hasn't quite caught on here yet.
My position is that all decisions should "protect the investment" and brand of MSFT.  That means innovate and appeal to other methods/technologies (as VS Code is doing a great job of doing), but do so in light of the history and tech that got us here.

This change is probably correct.  However the execution of this is absolutely insane. Right in the middle of RC2 and RTM is when you decide you're going to break every single application that uses C# Pascal cased property names because that's what the data serialized as.
Is this the decision making process going there?

Although the new behavior is what I'd like by default and this change would be reasonable in the beta fase, I don't think this kind of change should be done now (RC to RTM).
Indeed, it's very easy to roll back to the previous behavior, but you are requiring every application do to it. Plus, it's not hard to change to camelCase now.
I think the aspnet team should consider the impact of requiring every app out there to do it and other breaking changes like that.
Upgrading our app from RC1 to RC2 was a PITA. Among other things (like tooling, defaults, namespaces, etc.), we couldn't made our migrations work without deleting them all and creating again. We read the docs (which were very helpful), but it's a lot of work that don't necessarily add real value to our app.
I really hope that upgrading to new versions will be more easy to do than RC1 to RC2. We're not in beta anymore, we should be more restrictive in breaking changes. It's not even close to semver.

Updated description to show the configuration one-liner.

Hi all, this is indeed a significant change at a late stage in the product. No doubt about it. We've been working with @JamesNK (author of Json.NET) on this change and this is the quickest we could get it done. And it's pretty much a "now or never" kind of change. We recognize that this type of change can be painful for early adopters such as those here on this thread.
We feel that it is the right overall thing to do for the product, and though there is some short-term pain, there are long-term benefits that outweigh it. The general consensus on both this issue and on the original issue requesting the change (https://github.com/aspnet/Mvc/issues/4283) is quite clearly in favor of this change. We of course announce these types of breaking changes on the Announcements repo to mitigate the pain. And thanks to a simple, straight-forward design in Json.NET and ASP.NET Core MVC, it's quite easy to change the behavior back.
Thanks,
Eilon

Thank you @Eilon for taking the time to explain this.  My concern of course still stands, and it doesn't seem like you spoke to it, unfortunately.  Timing aside, can you speak to why you are choosing to inject a fundamental inconsistency in casing defaults between code and data for .NET solutions?  I understand that there was a general (overwhelming, even!) consensus in favor of this direction, but that was the case for project.json, too. :wink:
(too soon? haha)

can you speak to why you are choosing to inject a fundamental inconsistency in casing defaults between code and data for .NET solutions?

No good deed goes unpunished.

can you speak to why you are choosing to inject a fundamental inconsistency in casing defaults between code and data for .NET solutions?
No good deed goes unpunished.

My thoughts exactly

Hahaha... geeze, tough crowd.  Although I shouldn't be surprised.  I concede that I am in the minority here (at present).  Again, if all of your great work here was done in a vacuum this all makes sense and no problem.  But unfortunately since this is under the MSFT brand we do have to lend consideration to legacy/history and overall ecosystem.  These are exactly the same concerns I expressed with project.json over a year ago and no one paid notice to (or flat-out disregarded) my input then.  And wouldn't you know it, they eventually bore out into the costly about-face we're all (or really, you all :stuck_out_tongue: ) are having to endure at present. Maybe I will be patient and wait another year before someone with some clout can reverse the course of this questionable decision, too. :stuck_out_tongue:

@Mike-EEE My problem is that from my prospective this happened out of the blue. I understand that there were a significant number of core collaborators involved in the decision making process for this; however, it is a significant breaking change. For context, when I first saw the announcement issue it didn't even have a breaking change label nor the options code snippet to change it back.
I was also unware that camel case is the "convention" for JSON data naming. I even went as far to talk to some friends who are now enterprise devs working with other web stacks, and even they were unware that camel case was the "convention". The feedback I got was it was whatever naming convention they were using for objects in their code was the same convention they were using for JSON.
In addition, this has to be in the documentation for MVC. I remember starting out with MVC over a year and a half ago and expecting it to respect the naming conventions that I used in my code. Therefore, I strongly feel that this should be added to the documentation; that by default MVC won't respect the naming conventions you used for your objects.

Thanks for explaining @clarkis117.  That is some really great feedback and insight.
From my perspective, this issue is complicated by three factors:

The poor (inconsistent/friction-prone) guidance provided by .NET with its configuration system (web/app.config).
The desire to adhere to non-MSFT standards/conventions (to improve/increase favorability and adoption -- always excellent goals).
The fact that we now essentially (and unfortunately) have two MSFTs: a) legacy/enterprise/native developers (C#/Xaml) and b) web developers (C#/JavaScript/JSON).

While your concerns are primarily short term (and it's great to see you appreciate the long-term as well), I think this goes to show that we as a community need to start thinking in terms of profiles when we design features -- at least in the short to medium term.  This approach is not unlike the coding profiles you are introduced with in Visual Studio when you first install it.  This, however, affects the actual code and how it is initially configured before you actually get to coding it.
So in this case if you are a "native" developer, you get PascalCase by default, and a "web" developer gets camelCase by default.  And a "hack" developer gets snake_case.  I kid I kid... sorta. :smile:
Ultimately, however, the (long-term) root of the problem is that we are touching JavaScript (or non-MSFT/.NET languages) at all.  In fact, ASP.NET is the only primary product/group in MSFT that introduces and requires JavaScript for .NET applications, which is extremely disruptive.  What we should rally be focused on is to bridge the divide between "native" and "web" developers so that we are all working from the same conceptual client development model so that from top-to-bottom, through-and-through, we are all using the same constructs and idioms, and therefore, conventions.
Call me an idealist, though. :smile:

Again, if all of your great work here was done in a vacuum this all makes sense and no problem.

The irony here being that PascalCase is the result of decisions in a vacuum. Looking at literally the rest of the world, and seeing that you're doing JSON in what amounts to a proprietary way, should give pause and invite change. Not more myopia.

Not more myopia.

Haha!  Well again I am seeing your side, but it doesn't sound like you are seeing mine.  Well really not mine, but over 15 years of yes, living in a vacuum.  You're not really speaking to me, but hundreds of thousands of .NET developers and organizations who have spent their time loving their vacuum-sealed paradigm.
This is this history that continues to seem lost with some of the decisions made here.  I say some because what has been accomplished here is really great.  I am definitely a fan and big supporter.  .NET needed something like this in a big way.  We simply need to find a better way to make the decisions that "play nice with others" (e.g. EVERYONE ELSE BUT .NET LOL) gel well with the rest of the ecosystem that this product is a part of.
I am definitely open to ideas and dialogue here, I hope that is clear!

JSON in what amounts to a proprietary way.

Is that before or after we modified the serializer to accept inline comments? :smile:

Well again I am seeing your side, but it doesn't sound like you are seeing mine. Well really not mine, but over 15 years of yes, living in a vacuum. You're not really speaking to me, but hundreds of thousands of .NET developers and organizations who have spent their time loving their vacuum-sealed paradigm.

I do see that side - .NET Core had brought it into sharp focus.
If we'd done things the way they'd always been done, we'd still be squatting in the woods. There will always be those squatters for whom change is simply what jingles in their pockets. The world has gotten bigger since 2001; like it or not, the ostrich defense is paying less dividends now.
Optimizing for those static opinions, those immovable rocks in the river of innovation, is a recipe for staleness and irrelevance. Weep for those losing their capital letters; lament the death of their representational privilege; then step aside and let evolution happen.

  Ever.  Kudos to you, sir. :+1: :smile:

Also, there's an inherent naming disparity in the options setting now. If the default is now camel case and you're telling devs to set it to something with default in its name inorder to change it back; some are going to look at that and say, "bro, can you even name" :p

I must say I agree with the points raised by @Mike-EEE and @clarkis117 .

Having to change the JSON options to use a "Default" ContractSerializer is confusing. I understand the historical reason for this, and I guess there is no way to avoid that other than renaming that class which would cause even more problems, but this is a clear indication that ASP.NET Core is deviating from the .NET defaults.
In my opinion, camelCase is not a JSON naming convention, it's a Javascript naming convention. For people who use MVC/Web API as backend for non-Javascript clients this change is unexpected. I expect my .NET objects to be serialized the .NET way (even if I'm using JSON as the serialization format), and if I want to interoperate with languages in which camelCase is the default, I can explicitly configure .NET to use another serializer (the non-default one).
I understand that most people will use MVC with Javascript, my suggestion would be to set the camelCase serializer explicitly in the default MVC templates. This has the added benefit of not breaking any existing applications and aligns with the behavior expected (IMHO) by most .NET developers.
If WebAssembly becomes a thing, we may have a future in which we can write both backend and frontend code in C#/VB.NET/F#. If we leave the defaults as they are proposed here, we will have a PascalCase -> camelCase -> PascalCase "default" situation that will make even less sense.

@obraunsys

camelCase is not a JSON naming convention. it's a Javascript naming convention.

So nothing to do with JavaScript Object Notation? Ok... :wink:

@MaximRouiller
You are of course right about the origin of the name, and I know this statement can be controversial (which is why I started with "in my opinion"), however, I would argue that JSON has become a language-agnostic serialization format.
Please note that I agree that camelCase is the proper format when using JSON with JavaScript, but some of us also work with C# code on both sides of the pipe, and I have never seen anybody use camelCase in this situation (not saying it doesn't happen, I just haven't worked on any project where this was required or desired).

@MaximRouiller

So nothing to do with JavaScript Object Notation? Ok... :wink:

It's based off of JavaScript, but there is no official naming convention definied in the JSON spec. The fact of the matter is, It's entirely up to your use case/preference. However, as I previously said, I think it was a bad idea to make this change. Keep it PascalCase by default, as that's the languages naming convention. Let people apply custom rules as and when they see fit. This is just going to cause a literal fuck-ton of questions on SO, as newer people move to this framework and starting wondering why their API is outputting data that doesn't look like their data/view models.

@0xdeafcafe
As with every breaking changes, if we don't change it now... when will we? Probably never.
The good news is that new development will adopt the camelCase and those in a different casing scenario are literally just one line away from reverting back to the old behavior.
Damned if you do, damned if you don't. It's been the same reaction from everyone for everything that moves a previous default.

@MaximRouiller
I agree that now is the time to introduce breaking changes and start with a clean slate, but this is probably the wrong default for .NET serialization.

As with every breaking changes, if we don't change it now... when will we? Probably never.

While I respect that viewpoint (as it is rather accurate), I would like to point out @obraunsys's excellent observation about WebAssembly (which is really the "missing link" from a ubiquitous .NET client development model).  Once that kicks in this issue will indeed be a thorn in our collective sides.
There are, however (trying to be objective here -- and also maybe beat an objector to the punch :grin: ) a couple considerations:

WebAssembly might never materialize ( http://nooooooooooooooo.com/ )
WebAssembly materializes, but in a very delayed capacity, whereby this decision might not matter because we have moved onto the next fancy .NET Core.
Having a WebAssembly and by proxy a ubiquitous .NET client application development model would solve so many BIGGER problems (as in, removing JavaScript completely from our solutions, yay) that having to deal with this issue would be a welcomed problem in light of the very disruptive environment that we find ourselves between then and now. :stuck_out_tongue:

@Mike-EEE
So the positions against are the following:
Problem: We already have apps that use PascalCase!!!
Solution: One liner to change the default. People go back to life a happy and uneventful life.
Problem: It should be up to us to decide!
Solution: You already are. The defaults are just changed and can be changed.
Problem: WebAssembly might be a thing within the next 5 years. Let's no hurry too much.
Solution: Unless it's shipping now (or the next 6 months) and an issue in the very near future, let's not worry about this. Otherwise, we end up in a paralysis in case something important might be hindered by today's choices.
That's it. It's a non-argument. Defaults can be changed. Even in the case of WebAssembly, it's a non-issue since the default can be changed in literally one line.

Hahah I agree @MaximRouiller, it's all so very complicated! :smile:
The biggest problem to me personally (that isn't in your list) is the inconsistency with established (and continuing) standards from over 15 years of .NET development.  This change as designed at present simply introduces inconsistency (and resulting confusion) in light of .NET's storied history.
WebAssembly simply adds another dynamic to this, much like introducing a breaking change before RTM. :stuck_out_tongue:
Just think... if MSFT had done the right thing and simply gone the JSIL route rather than trying to introduce a completely incompatible language and client application development paradigm into .NET solutions, we wouldn't even be having this discussion in the first place. #cryingoverspiltmilk :grin:

@Mike-EEE This has nothing to do with "established .NET standards". The rest of .NET can and will go on with its existing defaults. This is MVC, a single .NET-based web framework, changing its defaults. Other frameworks, like Nancy, has changed these defaults a long time ago.
There is, of course, no standard when it comes to JSON property names, but AFAIK, the rest of the (web) world uses either pascalCased (most common), kebab-cased or snake_cased naming for JSON representations. After all, it isn't called JavaScript Object Notation for nothing. Google even has a JSON "style guide" suggesting you use camelCase.
Because we've wanted to follow the rest of the world, we've always been forced to change MVC's defaults, until now. As I mentioned in the other issue that suggested this change; this has always been the first thing I've had to change when setting up every single MVC/WebAPI application I've ever made. It's (about) time MVC changed to a more sensible default. If you want to use XAML, or keep the "old" defaults, it's completely up to you. These are just defaults, you're free to change them.

The rest of .NET can and will go on with its existing defaults

You mean with its existing inconsistent, conflicting, and contradictory defaults.

Google even has a JSON "style guide" suggesting you use camelCase.

Does that same style guide suggest comments in its JSON? :angel:

I mentioned in the other issue that suggested this change; this has always been the first thing I've had to change when setting up every single MVC/WebAPI application I've ever made.

And who's fault is that? :smile:  Again is this a MSFT product or a product that is developed outside of MSFT?  If it's a MSFT product, it should (ideally) adhere to MSFT standards, of which we know that PascalCase is indeed the default casing for all of .NET's languages.  Getting back to the unfortunate developer divide we find ourselves in, if we never had to deal with JavaScript, we never would have to deal with this discussion.  This is the only product/project/group that requires JavaScript for proper operation.  Now it seems all other MSFT groups/products/projects will suffer from an inconsistent default because of it.

It's (about) time MVC changed to a more sensible default.

It's about time MVC ditched the JavaScript. :stuck_out_tongue:

If you want to use XAML, or keep the "old" defaults, it's completely up to you. These are just defaults, you're free to change them.

The same case can be made for the reverse. :)  And they aren't just old defaults, they are established and ingrained.  This whole issue/approach/attitude sort of makes me want to say "MAKE MSFT GREAT AGAIN" or "MSFT First" as what is taking place here certainly isn't that. :stuck_out_tongue:
Again, this is a MSFT product based in MSFT history and this must be accounted for when considering these sorts of changes.  Has project.json taught us nothing? :stuck_out_tongue:  :stuck_out_tongue:  :stuck_out_tongue:

Is it possible, just possible, that the .NET renaissance could lead to an increased awareness of other communities? Perhaps we could admit that perpetuating cultural ignorance (in this case, the culture around JSON) might be counter to the strategy of an inclusive .NET?

@khellang, I agree that the reason for the change (it's what you want 99% of the time), is a damn strong argument.
I guess some of us have PascalCase ingrained in our brain when working with .NET and the new default will feel wrong, but the final decision should be what is best for the ASP.NET Core MVC ecosystem.
Just wanted to put my 2¢ in and voice my concerns regarding this decision.
Have a nice day guys!

I am reading this thread and I am thinking: Whats the big deal? All options are still available.
If I had to issue an opinion: JSON is based on Javascript and it makes sense to follow the dominant conventions in the Javascript world. It is irrelevant between which types of systems JSON is used for data serialization.

@Mike-EEE

You mean with its existing inconsistent, conflicting, and contradictory defaults.

Why should there be one default for all of .NET? The way it is today, on the web, .NET is the odd one out.

Does that same style guide suggest comments in its JSON? :angel:

Why would it? There's no comments in the JSON spec.

It's about time MVC ditched the JavaScript. :stuck_out_tongue:

I really don't know what to say here... It seems you've been living under a rock (or at least far away from the web) for a while :stuck_out_tongue_closed_eyes:
I see your argument though; why can't we just close out the rest of the world and live in our own warm and cozy little .NET bubble?

The same case can be made for the reverse. :)

But in your quote, you left out an imortant part:

Who do you want to optimize for? The 20% or the 80%?

Do you want to stick with the existing defaults and force 80% of people, maybe also coming from other languages/stacks, to change them? Or do you change the defaults and make the remaining 20% change them?

Again, this is a MSFT product based in MSFT history and this must be accounted for when considering these sorts of changes.

If we'd stuck with MSFT defaults and MSFT history, we'd still be sabotaging the web with IE6. Let's not forget and learn from history.

Has project.json taught us nothing?

I don't think (reverting) project.json was ever about angle brackets vs curly braces, so I'm not sure what it has to do with this... All its keys were camelCased. Are you saying that's why we're going back?

Whats the big deal?

It's the principle of the matter. :)

JSON is based on Javascript and it makes sense to follow the dominant conventions in the Javascript world
Again this makes sense if you are building a non-MSFT and non-.NET product that has nothing to do with C# or anything .NET-related.  However (and unfortunately) this is not the case as .NET Core is indeed attached to all of the history of .NET and MSFT.

project.json was a good example of this.

Why should there be one default for all of .NET? The way it is today, on the web, .NET is the odd one out.

100% correct if you look at it from a web-perspective, 100%-wrong if you look at it from a .NET (native/enterprise) perspective. :)

Why would it? There's no comments in the JSON spec.

100% correct, yet we have modified/adjusted JSON.NET and project.json to allow them (this was a prod towards deviating from standards, that obviously didn't take!).

I really don't know what to say here... It seems you've been living under a rock (or at least far away from the web) for a while :stuck_out_tongue_closed_eyes:

Hahaha... no I have been having to endure putting up w/ HTML5/JavaScript polluting our ecosystem since Silverlight bit the dust. :smile: ... or i should say: :frowning: :frowning: :frowning:

why can't we just close out the rest of the world and live in our own warm and cozy little .NET bubble?

While simultaneously reaching out to and embracing external developers, technologies, and communities.  I agree!  It's much easier said than done.

Do you want to stick with the existing defaults and force 80% of people, maybe also coming from other languages/stacks, to change them? Or do you change the defaults and make the remaining 20% change them?

Well who is the 80%?  From the web/adoption perspective the 80% is the webdev/JavaScript/HTML5 "web designer" crowd (that Visual Studio Code targets).  From the historical MSFT perspective, 80% would be the native/enterprise crowd.  Guess which one of these has put hundreds of millions (if not billions) of dollars into MSFT's coffers? :)

If we'd stuck with MSFT defaults and MSFT history, we'd still be sabotaging the web with IE6. Let's not forget and learn from history.

Fair enough (dang you bring up great points! I haven't quoted so much on GitHub as this post).  I suppose I should have said MSFT .NET/Developer history.  This has been very successful and has done much better than IE6 and a lot of other products.

Are you saying that's why we're going back?

project.json overlapped with MSBuild and Visual Studio tooling in so many ways.  This has been and was brought up for more than a year as votes and with issues in associated repos (example), but were essentially disregards and ignored.  It wasn't until the Xamarin acquisition and the enterprise groups starting to catch wind of project.json did everyone suddenly realize that there were a lot of scenarios (read: history and legacy) to account for that project.json simply did not fulfill, hence the reversal.
I am using that as a premier example of saying that the efforts done here impact more than just this project, and we should be mindful of the entire .NET developer ecosystem and be considerate, accordingly.

100% correct if you look at it from a web-perspective, 100%-wrong if you look at it from a .NET (native/enterprise) perspective. :)

Last time I checked, MVC was a web framework.

Last time I checked, MVC was a web framework.

A .NET web framework, written in .NET languages (which follow .NET guidelines). :)

This thread makes me want to leave .NET :sob:

:frowning: Really appreciate the dialogue and thoughts, though. :+1:

I was thinking maybe this should be red:

Folks, at this time we are not planning to change this decision. We feel we made the decision that overall makes things better for ASP.NET, MVC, and .NET. For those who are negatively affected by this decision, it's a simple switch to change the behavior back:
services
    .AddMvc()
     .AddJsonOptions(options => options.SerializerSettings.ContractResolver = new DefaultContractResolver());

Given that we are not changing the behavior, we would like to keep this thread focused around the change, as opposed to whether it's a good change or not.

CamelCase PascalCase  I really don't care, I think the goal is to get the data I want, if the client need camelCase ,then give it with camelCase, if client need PascalCase   then give it with PascalCase  , if client need both , give it with the the client need,  someone like( or need) camelCase you can write camelCase Object or Use  [JsonProperty("myName")] on MyName property .
  And i'm sure  it will generate PascalCase json when you write object in PascalCase.
Other side: if you write a C# object
public class MyData
{
    public string WWTUrl { get; set; }
    public string W3CUrl{ get; set;}
}

serialize to
{
    "wWTUrl":"http://www.worldwidetelescope.org/",
    "w3CUrl":"http://www.w3.org/"
}

Is that will feel good ?
sorry for my bad english

For those who are negatively affected by this decision, it's a simple switch to change the behavior back:

Totally missing the point here. :)  But that was the case for project.json as well.  Sooooo... I will just let it ride until someone with a little more clout than little ol' me sees the same thing and interjects.

we would like to keep this thread focused around the change

Well, if you insist.  What about the now odd/awkward position of having DefaultContractResolver no longer being default?  Seems like there are two breaking changes here as DefaultContractResolver will have to be renamed.

What about the now odd/awkward position of having DefaultContractResolver no longer being default?

Talk to @JamesNK? or do a pull request? :stuck_out_tongue:
Source: https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json/Serialization/DefaultContractResolver.cs

Well, I'm at least happy that I won't have to configure all of my projects to use a community-friendly JSON style. The looks I got from front-end devs the first time they saw my PascalCase JSON, yeesh.

If you are on the web then camelCase is the accepted standard; if you are in a closed system you can change the default, can also happily use the xml serialisation if that's your thing.
If you are not on the web generally interconnected systems are now no longer homogeneous and written in one language or on one O/S; so you don't want .NET backed apis to standout as the incongruous ones.
If you are exposing your apis publicly, or hope to do one day, you definitely want camelCase as you can't and shouldn't determine your customer's choice of language or development tools - unless you want less customers - so I applaud this change.

In every project I ever worked in, all frontend devs has DEMANDED camelcased JSON, so I really like this decision, great work.

@Eilon > Given that we are not changing the behavior, we would like to keep this thread focused around the change, as opposed to whether it's a good change or not.
So where do we take up our issues with how this change was done out of the blue and immediately before "RTM"? Or were you directly telling us to shut up?

@dotnetchris the change was discussed starting on March 14th, which is nearly 3 months ago now: https://github.com/aspnet/Mvc/issues/4283, and got near-universal support from the community (over 100 upvotes, which is more than any other issue in all of 'aspnet').
Then, 19 days ago, I mentioned that we decided to take this change.
Then, earlier in this thread I gave further reasoning for why we did this change.
This thread as well also shows that people are overwhelmingly in favor of this change.
We know we can't make everyone happy, but this change clearly makes more people happy than sad.
Thanks,
Eilon

I appreciate your time in taking a moment to express the reasoning behind this, @Eilon.  It really means a lot.
My primary concern here, and I will simply say this and shut up (well OK, probably not. :grin: ) is that this change affects much more than this repo/product/project.  Of course it is going to have high marks here, (much like project.json did/does), but externally, it might not do so well.  As long as you understand that and you have heard me, then I am OK with this.  Clicking on all the positive reactions below your comments.
It will finally make it easier to integrate with AngularJS/KnockoutJs/[insert other JS framework] in the future. Thanks for making this decision.

@Mike-EEE After double checking, this will not impact you unless you are parsing JSON by hand.
If you are using JSON.NET to generate/parse your data? No impact what so ever unless you are serializing Dictionaries. Assuming that behavior hasn't been fixed already.
Source

@MaximRouiller Can you please explain what you mean by parsing by hand?  As in it will only affect my files if I am editing them and not using the serializer to create them?
And no, I don't use JSON.  I avoid it as much as humanly possible.  I am all Xaml all the time 100%. :)  Again, to me this is the principle of the matter, and I am also trying to speak for enterprise/native developers as well.  Guess they will just have to chime in at a later date. :open_mouth:

@Eilon so the first time i heard of this was when the aspnet announcement appeared in my git inbox. How would i have been made of aware of this sooner that I could have actually provided feedback prior to the final decision being made? It doesn't seem like anyone in this thread expected this decision and that everyone was surprised. There's clearly a gap here.

@Mike-EEE this is about the property casing used specifically for the JSON serialization format used over http/https when used via Web Api.
You can also use XML as a serialization format among others and that will be unaffected by this change.
If you are not consuming web api REST endpoints, you will also be unaffected by this change.

@dotnetchris
@Eilon mentioned that it was [talked about](https://github.com/aspnet/Mvc/issues/4283] 3 months ago.
If you want to get part of the discussion, you can subscribe to this repository and get in on the discussions!

@benaadams and @MaximRouiller (and really everyone haha) OK I am with you now.  Thank you for your patience and great dialogue!

@dotnetchris all discussions related to the MVC product tend to happen right here, in the MVC repo. The Announcements repo is for things that have happened, whereas the individual "product" repos are for work we are planning and debating.

@dotnetchris  Is there a way to make a exception in CamelCasePropertyNamesContractResolver ? I run a test use [JsonProperty("PascalCaseName")] , and it does not work .

@Eilon what's the purpose of these discussion threads at all if everything is a done deal and the ship has already sailed? the way i originally understood the purpose of the announcements repo was to put a much more curated feed out. It seems largely, if not entirely, pointless given this thread.
What purpose does this thread at all serve?  What is there to discuss if announcements mean "this is it"?

@dotnetchris as I mentioned several times now, this change was discussed at length for nearly three months before making the change, and for a few weeks once we committed to making the change, and only then did we actually make the change. I'm not sure what you're asking us to do differently in the future.
I'm sorry this change doesn't sit well with you, but I feel that we followed an open process for making this change: we listened to what customers asked for, over one hundred people were in favor of it, almost no one was against it, and so we made the change. We discussed the change with @JamesNK , the author of Json.NET, and a well-recognized figure in the community, and even got a new feature in Json.NET that would make this a safe change to make. And as we see in this thread, it seems to me that most people also agree that this change had sufficient visibility and awareness prior to it being made.
We encourage open participation in this project by monitoring the specific product repos (MVC, EF, Razor, Kestrel) and adding comments and voting on issues.

We understand the open process @Eilon (now :smile: )... but it does seem that creating a discussion thread after the fact is a little late in the process (or really, not very valuable at all).  I think what @dotnetchris is suggesting is perhaps tweaking the process/workflow here so that the community can provide more/better input sooner.
It's a tricky problem, as I personally do not subscribe to these repos (there are a LOT of notifications, as you well know).  However, I do subscribe like a monster to RSS feeds to pretty much every MSFT blog there is, so that is how I get my information.  If there was an announcement to discuss a breaking change on a blog post I would see it, FWIW.
It would be even better if GitHub provided an alert or "critical notification" that also allowed us to know when super important issues are going down, as well.

@Mike-EEE Currently, it's everything or nothing.
If you watch a repository, you'll be informed of every event on any issues.
This is a GitHub issue. By experience, blog posts are just like "announcement" but with less detail than what we find on GitHub.

Yeah I hear you @MaximRouiller, just expressing some thoughts.  Not saying I have the answers, just suggestions.  I am curious on how many notifications this repo sends out a day.  I am already subscribed to a few and it's quite chatty.  Basically goes straight to a outlook rule. :stuck_out_tongue:

I am personally only watching Announcements.
I do not have enough time to participate in design discussions. I believe that the .NET Team will deliver a workable product that will build upon standard, common practice and good faith.
So when something as simple as a default is changed, I don't blink. Not until we hit RTM and they deliver 1.0.1.

Yeah same... I do have Announcements watched, which is what landed me here.  The suggestion/ask/desire here is to get a "Pre-announcement" mechanism where we can somehow join the conversation before it gets to this point, but I am not sure that is easy/possible ATM.

@Mike-EEE
Then you get to the problem where it's decision by committee where the committee might not even contribute (or be able to).
If you exclude design by committee, you end up with a repo that is used for asking if it breaks anyone and you don't need a repo for this. It will always break someone. In any scenario, I'll trust the team until they go crazy. Then, I'll speak. I don't have time for anything else.

Also, what qualifies for a "pre-announcement"? Sorry @Mike-EEE. Either you get involved (watch the repo and give feedback), or you don't. Simple as that.

LOL geeze duders, I'm looking to help out here.  The goal/ideal here is to get visibility to changes that people may or may not be interested in.  If there are 100 people that like an issue, but there are really more like 500 that don't like it, this might be valuable to know.  It's basically improving/increasing visibility of important topics without increasing noise to the average user.  This is not asking for more cooks in the kitchen (design by committee) but more visibility which leads to more participation (think: GitHub reactions/votes rather than long exhausting threads like this one for the most part -- ideally), which leads to happier developers which leads to happier community which leads to a better product.
In theory. :smile:

@Mike-EEE
With what happened to https://github.com/aspnet/Home/issues/1433, I believe that there will be too many cooks in the kitchen. Or at least, lots of sideline coach. Each wanting to contribute, but lots of them not having a complete big picture and none doing any actual basic Proof Of Concepts or Pull Requests. And that is if they even installed the actual framework.
So let's retake the same scenario. Change of default to the JSON Serializer. What would a discussion on the subject would have look like? I'm not sure but I'm betting lots of people would have said exactly what was said here. We would either still be discussing it or it would have been approved anyway and people would have complained that Microsoft wasn't listening to comments.
tldr I'm ok with how things are.

I understand your concern @MaximRouiller.  I hear you haha.  The difference between what we have now and what we're discussing is that we would have dialogue BEFORE any changes were made, rather than after.  I would feel better if:

I knew before I jumped into this discussion that it was "already too late" for any sort of change.
I knew beforehand there was some way of voicing my concerns (or more importantly in my mind: votes/reactions -- ala GitHub reactions, which at present is the greatest instrument for measuring sentiment) about this issue before it was sold and set in stone.

I'm OK with having my vote rejected, as long as it is heard.  I am not OK with not having my vote utilized or counted or making it in the tally in the first place -- regardless of the reason.  We can chalk it up to my ignorance (lack of tooling/notifications), or poor process, but the fact that my vote (or anyone's vote) didn't make it into the final tally is really what should be the focus here, and what I am driving at.
Again it is all about promoting awareness and participation so that as many metrics as possible are provided to the stakeholders and drivers to the repo.  Hope that clarifies my position. :)

@MaximRouiller  @Mike-EEE Do I hear a need for a discussion on changing the default serialization format for Web APIs to Protobuf? ;-)

@Elion added suggestion to https://github.com/aspnet/Home/issues/1571 on a way to make breaking changes more visible while they are still at the "potential" stage

@Mike-EEE would that help?

Does it ever!  Thank you for pointing that out, @benaadams!  And thank you, @Eilon!!!

It's ok to have the serializer configurable, but, it sounds weird to be forced to tweak the configuration when you want to use the default configuration of the serializer (DefaultContractResolver).
It would be far more intuitive to tweak the configuration when you want anything different than the default... wouldn't it?

@SocVi100
DefaultContractResolver is only default as far as its name. It was probably called default because it was the default way of serializing in .NET before (think DataContract) JSON.NET became popular.
Maybe we should ask @JamesNK for some history on the naming. ;-)
And yeah... DefaultContractResolver is part of JSON.NET. Not .NET.

@SocVi100 DefaultContractResolver is a Json.NET class, it's not an ASP.NET Core MVC class. I think it'd be better named as PascalCaseContractResolver.
I agree with you... it's confusing.

@fhelwanger    the DefaultContractResolver is not PascalCaseContractResolver  , you can use DefaultContractResolver  to generate camelCased json when you write camelcased C# property or use [JsonProperty("cameCaseWords")] . This is why it called default , because it don't change any thing you write . and PascalCaseContractResolver   sound like it will change anything you write to PascalCase

@John0King You're right, thanks!

Does some one tested the workaround?
services     .AddMvc()      .AddJsonOptions(options => options.SerializerSettings.ContractResolver = new DefaultContractResolver());
It doesn't work in my case for some reason (.net core 1.0 RTM), still have propertyName in JSON. What it can be?

@antonGritsenko that's my work around too, working fine for me.

I like this change and I also wrote a little blog so that more people can know about this change.
Blog is here.

@NeelBhatt - I read through your blog, thanks!

camelCase is the default - services.AddMvc() will give you camelCase
If you want the old PascalCase behavior then do
 services
        .AddMvc()
        .AddJsonOptions(options => options.SerializerSettings.ContractResolver = new DefaultContractResolver());

Your blog post seems to give the impression that it's the other way around

@rynowak Thanks for looking into it and for the feedback.
I have updated my blog accordingly.

I just encountered an interesting scenario with camel-cased names and wanted to ensure we account for it.
The default serialization for a Dictionary<,> is to a JSON object:
{ "foo": "...", "bar": "..." }
However, if we serialize an upper-cased key Foo, it will become lower-cased as a property, then deserialize back with the lower-cased name, creating a lossy conversion.
We worked around this by creating a DictionaryConverter that treats dictionaries as List<KeyValuePair<K, V>>:
[
    { "key": "Foo", "value": "..." },
    { "key": "bar", "value": "..." }
]

We wanted to simply tell JSON.NET to use JsonArrayContract for dictionaries, but had to account for existing data that uses the object-not-array format.

@bwatts did you open an issue on https://github.com/JamesNK/Newtonsoft.Json?
If it's a bug, @JamesNK should be informed. I've looked quickly at the repository and it doesn't look like this issue has been logged before.

@MaximRouiller I wasn't sure if it is a bug or just an unfortunate feature collision. I'll open an issue over there anyhow to be sure.

@bwatts @MaximRouiller Camel-case dictionary keys is something that needs to be opted into. If you want to tweak the settings, you can set the JsonOptions:
services.AddMvc().AddJsonOptions(x =>
{
    x.SerializerSettings.ContractResolver = new DefaultContractResolver
    {
        NamingStrategy = new CamelCaseNamingStrategy
        {
            ProcessDictionaryKeys = false // this is the default.
        }
    };
});

Thanks @khellang for the clarification! Didn't know about that specific feature.

@khellang I found NamingStrategy and ProcessDictionaryKeys while investigating, but this fiddle seems to contradict that default. Thoughts?

@bwatts Uuh. CamelCasePropertyNamesContractResolver isn't the same as DefaultContractResolver :wink:
This fiddle shows that it works :smile:

For dictionaries, I'm using this: http://stackoverflow.com/a/24226442/214073

@khellang isn't the point of the MVC default-to-camel-casing to make the CamelCasePropertyNamesContractResolver the default?

@bwatts No, because as you've discovered, CamelCasePropertyNamesContractResolver also makes dictionary keys camel-cased. That's whay @JamesNK introduced the NamingStrategy class. MVC uses the DefaultContractResolver with NamingStrategy set to CamelCaseNamingStrategy, which has ProcessDictionaryKeys set to false by default.

@khellang got it - so it seems I shouldn't be using CamelCasePropertyNamesContractResolver at all then. I didn't realize.

This change is really ridicilious. You need to tell mvc to use default serializer to get the default behavior. This is why microsoft is not liked by many.

@gr3ysky The problem is "the default for what scenario"?
It's all a matter of choices.
At least now, we know what they're choices are more or less when they happen and we have a way to tailor things to our liking.

The default is the f.cking default. No need to argue on what is default. It shouldnt change the property names. It is just like start menu issue. I have been developing mvc over six years. It was pascal case till now. And just check the code to get old behaviour. And thats silly to say use the default behavior. Right?

@gr3ysky Did you read https://github.com/aspnet/Mvc/issues/4842#issuecomment-228834315?

Further, you're arguing defaults should never change? This is a major version.
First thing I do on every project is change the "default" so I get "proper serialization" for javascript.
What's "right" is a judgement call, not an objective fact.

The new "Default" for serialization in JSON is now lower case.
The model binders for ASP.NET Core will interpret lower-case/upper-case without any issues so this is a non-issue for "current behavior" of the API.
So let's take a look at what scenarios you would need to change it.

New Project
Porting to .NET Core

Here are the solutions:

Either the invoking client adapts to the API it invokes and parse the data properly or you adapt to the client and do a one line change of code to suit the invoker. Either way, minor change.
You are porting an API from .NET Framework to .NET Core. So between the whole HttpApplication going away, the application lifecycle being modular, project.json, WebAPI/MVC being merged, Kestrel as a running host, EF Core != EF6, lack of Azure integrations, dependency injections as a first class citizen, no oData support yet, missing libraries that haven't converted to Core... and what is a deal breaker is ... default serialization for JSON.

It's a major rewrite of a framework. You can't expect to copy/paste your code and expect everything to be feature equal. I have more complaints about EF Core right now than the default serialization for JSON which can be reverted in one line of code. As mentioned before, there's only Microsoft that defaults the JSON serialization to Pascal Case. Now we are "back to normal" in the web sphere.
If you want to go back to the good old days when you are porting an application, here's how:
services.AddMvc().AddJsonOptions(options =>
            {
                options.SerializerSettings.ContractResolver = new DefaultContractResolver();
            });

Is it by design that ModelState is serialized as pascal case? I don't mind the change of default to camel case, but I'd expect it to be consistent.

We are closing this issue because no further action is planned for this issue. If you still have any issues or questions, please log a new issue with any additional details that you have.

If I could, I wanted to thank everyone for the respectful and thoughtful discussion on this memorable thread, especially when it turns out I had no idea what I was talking about. 😛 (or to be more accurate, did not completely understand the issue at hand and misunderstood its actual implications).
I'd also like to send a special shout out to @bwatts for his "no good deed" comment above as well.  I didn't really understand it at the time, but there have been been numerous instances since then in other discussions throughout GitHub where I have been brought to bear the full appreciation of that statement, LOL.  If it helps at all, rest assured that I have gotten my due on the flip side. 😆
Anyways, thought I would share.  And no, I can't help it. 👍

It is interesting that if an object is not strong type like object or dynamic, it will not be converted to camelcase. But it can be fixed by
     .AddMvcCore().AddJsonFormatters().AddJsonOptions(opts =>
                {
                    opts.SerializerSettings.ContractResolver = new CamelCasePropertyNamesContractResolver();
                });

Or by using the DefaultContractResolver and setting ProcessDictionaryKeys = true (which I think is recommended):
 .AddJsonFormatters(json =>
 {
     json.ContractResolver = new DefaultContractResolver
     {
         NamingStrategy = new CamelCaseNamingStrategy
         {
             ProcessDictionaryKeys = true
         }
      };
});

Wow! I found this ugly bug! And it is a really bug!
This behavior broke the data exchange between C# and JS!

All properties in JS must be fixed after migration from ASP.NET
Doesn't have backward compatibility (to restore broken case) and can't be returned AS IS to the ASP.NET Controller

public class TestModel
{
  public int Id { get; set;}
  public Dictionary<string, string> Settings { get; set; }
}

Simple method to use model
<script>
    var model = @Html.Raw(Json.Serialize(Model)); // case is broken there when ASP.NET Core used

    // some methods to bind inputs with model

    $('form').submit(function (e) {
        e.preventDefault();
        $.ajax({
            url: this.action,
            data: JSON.stringify(model),
            type: "POST",
            beforeSend: function (xhr) {
                xhr.setRequestHeader("Content-type", "application/json");
            },
            async: false
        });
    });
</script>

Simple method which must save returned model
[HttpPost]
public ActionResult YmlConfiguration([FromBody]TestModel config)
{
    // config = null and NullReferenceException fired there because case broken!
}

It is improbable to change names at serialization! Why?

@QuAzI If you want to restore the older behavior of keeping the casing, see the comments above. They show you many ways to resolve that issue.


TST: Verify fix for buffer overflow in read_csv with engine='c'

Tests for the bug in GH #9735, which was previously fixed in GH #10023.

thanks!


Add tests for EVP_Q_* functions

Recently, new public functions have been added to improve usability:

PR #14664 added EVP_Q_mac()
PR #14741 added EVP_Q_digest()

Both were merged, but we missed they did not include tests for the new functions.
This is partially mitigated by the fact that they act as wrappers around the underlying functionality which has tests.
We should add the missing tests for the high level functionality, also as a way to exercise in more combinations the coverage of the underlying functions.

@DDvO can you work on this?

@DDvO can you work on this?

I was about to start working on that,
but found that I would only be able to come up with a rather basic test for each of the two functions.
So I suggest someone else does this who can provide some more in-depth tests with sufficient coverage.

The underlying functions for EVP_Q_* are already tested, and seeing that these functions aren't terribly complex, there's only so much that needs coverage.  I would suggest adding a few more tests in test/evp_extra_test.c.

Would for instance
static int test_EVP_Q_mac(void)
{
    static unsigned char static_md[SHA_DIGEST_LENGTH];
    size_t outlen;
    char *p;

    /* Test EVP_Q_mac with NULL key. */
    p = pt(EVP_Q_mac(NULL /* libctx */, "HMAC", NULL /* propq */, "sha1",
                     NULL /* params */, NULL /* key */, 0 /* keylen */,
                     test[4].data, test[4].data_len,
                     static_md, sizeof(static_md), &outlen),
                     SHA_DIGEST_LENGTH);
    return TEST_ptr(p) && TEST_int_eq(outlen, SHA_DIGEST_LENGTH)
        && TEST_str_eq(p, test[4].digest);
}

in test/hmactest.c make sense?
Unfortunately, the existing test data there does not include a key.

I would also include some tests that compare the output of EVP_Q_mac with the output of the underlying functions and the convenience macros for compatibility with legacy.
This kind of testing I am proposing does admittedly little regarding the correctness of the output (at least for now), but is a way to formalize that legacy code, EVP_Q_* and the more elaborated way that uses EVP_MAC functions all are supposed to be backward/forward compatible in their behavior.
This will prevent us from changing something in any of these 3 points of duplication without noticing that we are breaking some promises.

@DDvO, that's exactly what I had in mind (with TEST_mem_eq not TEST_str_eq).  I don't think much depth is needed here, just a single basic known answer test for each of the two calls is enough.  The algorithm is tested elsewhere, just the function interface needs testing.
Perhaps use something other than HMAC since that path is well covered already.  CMAC is the obvious choice since it is different but KMAC or GMAC would be reasonable picks.

I've hooked these two calls into the evp tests in #15888.  We should be getting fairly comprehensive testing from this.

I find it a little over the top to hook it into test/evp_test.c.  After all, EVP_Q_mac is just wrappers, so what you end up doing is essentially to run the exact same EVP_MAC functions twice.  The same goes for EVP_Q_digest, but it's a wrapper of a wrapper, which is probably the reason why EVP_Digest is tested in test/evp_extra_test.c.

It also checks that all the different MACs can be run via the EVP_Q_mac call.  That's not going to happen if the is relegated to evp_extra_test or equivalent.
Including SipHash found a problem with the calling code I began with.  I wouldn't have found the issue otherwise because no other MAC exposed it and SipHash wouldn't have been something I'd have chosen.

The further this discussion has come, the more I see that this topic is not my turf -
I can treat crypto algs only as a black box, and luckily this is sufficient for the use cases I am actually involved with.
So I'm glad that @paulidale has taken over providing some (in my limited understanding) pretty general test cases.
@romen, since you seem to have specific ideas which tests to add, I wonder why you did not do that yourself.

@DDvO Just time constraints at the moment, otherwise, yes, I would have opened just a pull request. For now I am happy to review a PR with some tests and give suggestions, and when I will be able to I will integrate with my own PR if I think there is more that I would like to be tested!
In general, I hear @levitte argument that "this functionality is already tested through the underlying functions elsewhere", what I would like to be tested here is actually API testing rather than functionality testing.
We have the complex EVP_MAC way, the quick EVP_Q_mac way, and the "legacy macros" way of achieving the same result to compute hmac, cmac, etc. through different entry points.
As we promise these entry points are equivalent, we should test that this expectation is met (for hmac, cmac, etc.) and prevent that future changes break things in subtle ways.
Otherwise we risk ending up with other cases of documenting one thing when functions are created, altering functionality in subtle ways, discovering years later inconsistencies between docs and code and setting for the latter because "this was never enforced/tested".
Whenever this happens, we send a very bad message about our documentation and the guarantees of its consistency.
One way to prevent this to happen again (and the reason why I am suggesting it) is, when we document "this is just a wrapper for X", "Y called with such and such arguments is equivalent to Z", etc., that we also write tests that bind our intention to what the code actually does.

I suppose the MAC and digest tests are quick enough that it really does not matter whether we test them twice or not.

Yes, they are very quick.
Public key and KDF tests might need to be more discerning.


Rewrite lambdas and Add Transfer volume across AZ's

Could you please submit this to the dev branch?

Changed to dev.
P.S. Thanks, I like working with AWS)


Unable to upload to the gcp bucket directly

using the mentioned code for in the document unable to upload mpd files directly to the cloud

It seems like your question is related to the python-ffmpeg-video-streaming (as your previous question was related to that) not this repository.


Create cz

Czech language mutation

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@MichalAnthis Why have you close everything?

@lucasbrazi I closed the previous one, and made new ones with the correct files, to avoid complication.


Stable 1.11 backports

Changes in this backport
42ec8413 virtiofs: Disable DAX
fd75db90 virtiofsd: Use cache=auto
6239df7f virtcontainers: fix delete sandbox failed problem
ec12ddbb shimv2: handle ctx passed by containerd
7b09e967 sandbox: Disconnect from agent after VM shutdown

@egernst  I have tried to backport #2972 but does not apply directly.

/test

/test

removed dax patches, I see merge was having problems, doing as experiment to see if those commits where the problem

@jcvenegas, if possible, I'd like to suggest to have the cgroups fixes Eric worked on backported as well: #2944 and #2988.

/test

/test

/test

/test


Fixes #303. Replaced dynamic styling with class-based CSS approach.

Fixes

Fixes #303 by @Murdock9803

Description
This PR addresses the issue where dynamic styling was being used to control the visibility of resource cards in the _assets/js/listing.js file. To enhance maintainability and consistency, the following updates were made:
Introduced new CSS utility classes (.hidden and .visible) to handle the visibility of resource elements without relying on dynamically injected styles.
Refactored the updateVisibility function to utilize these new classes, ensuring that elements are shown or hidden based on the user's filter selections (topic, medium, language).
Adjusted the resource navigation filters to dynamically apply the appropriate visibility classes, providing a cleaner and more efficient way to control the display of filters.
These changes align with the suggestion to replace dynamic styling with a class-based approach, making the codebase more consistent and easier to maintain.
Checklist

[x] My pull request has a descriptive title (not a vague title like Update index.md).
[x] My pull request targets the default branch of the repository (main or master).
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[ ] I added or updated tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no
visible errors.

Developer Certificate of Origin

For the purposes of this DCO, "license" is equivalent to "license or public domain dedication," and "open source license" is equivalent to "open content license or public domain dedication."

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

@poojatalele  you should make more descriptive Pull Requests. The fields are almost all empty. You can remove them if not necessary.

@poojatalele you should make more descriptive Pull Requests. The fields are almost all empty. You can remove them if not necessary.

Updated all the changes, kindly review.

@poojatalele thank you for this contribution!
After looking through there are some improvements that could be made to streamline it a bit further. Since the default state is visible, we don't need a visible class, and could instead only have a hidden class and utilize the classList.toggle method rather than the classList.add and classList.remove methods.
For a somewhat similar example of approach see the vocabulary.js file.

@poojatalele thank you for this contribution!
After looking through there are some improvements that could be made to streamline it a bit further. Since the default state is visible, we don't need a visible class, and could instead only have a hidden class and utilize the classList.toggle method rather than the classList.add and classList.remove methods.
For a somewhat similar example of approach see the vocabulary.js file.

Okay, got it! I'll update the changes.

@poojatalele Thank you! 👍

@Murdock9803 @possumbilities Replaced classList.add and classList.remove with classList.toggle.
Kindly review :)

The changes here break the function of the filters after recent UX work. Closing, and would suggest it be revisitied with current work merged in.


Show brand field for cinema preset

This relates to https://github.com/openstreetmap/iD/issues/5515
By convention iD will show:

both the "name" and "brand" fields for presets where we may want to lock the "brand" and let the user change the "name", and
"name" only for presets where we might want to lock the name

Cinemas are in the first category and should show both "name" and "brand" so users can customize the name field, e.g. "AMC Mountainside 10"

As far as I can see, the cinema preset already has the brand field (since https://github.com/openstreetmap/iD/commit/5ab713462a755ef69ec616a8f59786f8264c351b). Am I missing something here?

Oh yeah, I think the behavior I described only happens if the field is in fields but not in moreFields.
But I don't need this anymore, I added a workaround in the NSI project to generate the branded presets with the name and brand/operator fields up at the top of the fields array.


Change C# Code

Hi, I tried this example and it doesn't work out-of-the-box, as the client tries to connect to the broker without using the username and password, which of course doesn't work. The correct line (181) is commented out. I haven't seen it mentioned and it took me a while to find the issue, so maybe change that for the next version.
Thanks!

@EvaKaul  please double check the issue mentioned by Milan

fixed with merge on 28.02.2023


Styling

First iteration, adding lights projecting colors in the mesh:
https://user-images.githubusercontent.com/49062/133999464-4b2bc318-599f-4698-9ffb-2aa3db38445e.mp4
Second iteration:

Galaxy particles orbiting the canary model
Glitch effect and bloom post-processing pass
All colors following the brand palette

https://user-images.githubusercontent.com/49062/133999488-ea8b956e-8bc7-4a9b-8a68-6e3150dbeb7f.mp4

Increased number of vertices to 1500 to test higher bound and decreased size of vertices from:
![Screenshot from 2021-09-26 22-33-58](https://user-images.githubusercontent.com/49062/134892547-7b1ce5b1-8343-4b11-869c-749d8c663494.png
To:

)

Original mesh and vertices with no bloom effect:

Only vertices:

Vertices with single color (subtle) mesh:

"Reflective" mesh:

Some video shots of the same configurations as above.
Only vertices:
https://user-images.githubusercontent.com/49062/134898213-a2bdfcce-5593-4a0f-b293-d11e9fbdfa0c.mp4
Simple mesh:
https://user-images.githubusercontent.com/49062/134898273-2aac703d-004a-49a4-beb9-6fb82a98ced4.mp4
Reflective mesh:
https://user-images.githubusercontent.com/49062/134898322-89f2970c-228a-4450-89b0-b9408b05cbf5.mp4


HIV Management - Diagnosis

Issue
When a patient comes for the first time for HIV management, the positive test date should be obtained (or estimated). Once the positive test date for this HIV management participation has been established, it does not need to be asked in subsequent visits.
If the patient has a positive HIV lab test in E-Heza**

Show: The patient tested positive for HIV on [date]
Ask: Is this correct (Yes/No)
If yes, record the date of HIV management as the "positive test date"
If no, Ask "Date of positive test:" while providing an "Estimated" check box (as in birthdate for patient registration)

Yes(Date is Correct)
No, Date is not correct

** Note: there are quite a few ways in E-Heza where we record a patient's HIV status (registration, ANC Partner information, etc.). In this module, we are only concerned with a positive HIV Lab test, HIV status is otherwise ignored for the purpose of this module.
If the patient does not have a positive HIV lab test in E-Heza

Ask: "as this person diagnosed with HIV? "
If no, exit activity.
If yes,  Ask "Date of positive test:" while providing an "Estimated" check box (as in birthdate for patient registration)

Todo

Implement as per design
implement the Logic

@adamhstewart

and if only they have not been previously diagnosed

How do we define this?

@anvmn I re-wrote the issue to answer the question and provide some more scope for this activity.
@Diama1 we need some designs to reflect these changes that were discussed.

@Diama1 we need some designs to reflect these changes that were discussed.

@adamhstewart Done

https://nutrition-ihangane.pantheonsite.io/app
QA Review
Found issues and questions
Checked and approved:

If patient was not diagnosed with HIV, encounter is ended.
If patient was diagnosed with HIV, question about test date appears.

@anvmn Change "What was the positive test date?" to "When was the positive test date?"


multi-thread support on the RiteVM

Introduction
I know that current RiteVM is not supporting multi-thread.
And mruby do not have the plan to support multi-thread.
But, I want to use some libraries that are made on the assumption of multi-thread.
Let's discuss about multi-thread support on mruby.
Current implementation

mruby-thread (made by @mattn)

Why the VM instance is duplicated?
Please see this tweets by @mattn (in Japanese only)

https://twitter.com/mattn_jp/status/402216538494615552
https://twitter.com/mattn_jp/status/402217305142067200
https://twitter.com/mattn_jp/status/402218656190324736

He said,

GIL (Global Interpreter Lock) will give too big effect.
We have no way to clone (or duplicate) context on the created VM instance.
Some mruby extension codes (mrbgems) contains 'mrb_state' into user defined class instance. So, we cannot share the object between threads (Because RiteVM is not thread-safe).

* (comment) is added by author.
Multi-VM vs GIL
I think, Multi-VM method is not good.
Because we cannot share any variables between threads.
And we have to write curiously code (see below) to assign the variables that is shared between some threads.
object migration in Multi-VM method:
foo = migrate_object(bar) # bar is shared
But I want to write like this.
foo = bar
I do not hope to supply special procedure for well known programming paradigm like multi-thread.
So, I think that GIL is better than Multi-VM method.
But GIL have performance problem.
I would prefer to make RiteVM thread-safe without GIL.
Thread-safe RiteVM
I wrote experimental code for thread-safe RiteVM.
https://github.com/crimsonwoods/mruby/compare/experimental_thread_support
We can make RiteVM thread-safe by narrow lock mechanism, maybe.

What do you think about multi-thread support on the RiteVM?
Thanks.

@crimsonwoods
https://github.com/crimsonwoods/mruby/compare/experimental_thread_support
Thanks.
Ok in future @matz add this in main tree?

Merging this would make mruby doesn't work on non threading environment. It should at least be pluggable/configurable.

Ok if i try rewrite it and make configurable?

At least I promse to review the code.

@killer2tester
Thank you for your wonderful proposal!
1 year ago, @matz said, "we have to compare GIL/GVL implementation with multi-VM implementation". I have not been able to do it. Currently, I think, we cannot make decision about implementation of concurrency in mruby. Because it has big impact to every mruby developers. Many mruby developers might be interested in the argument about concurrency and threading implementation.
And, maybe, anyone have no answer for it. Of course, me too (@matz might be also same).
If @matz did not change his mind, you might have to compare GIL/GVL with multi-VM method.

Hi everyone,
I implemented experimental multi-threading support in mruby with GVL.
https://github.com/crimsonwoods/mruby/tree/implement_multithreading_support_with_GVL
This is based on mruby 1.1.0 tag.
And including changes below:
Breaking changes

mrb_state structure is split to mrb_vm_context and mrb_thread_context structures.
We need to use MRB_GET_VM, MRB_GET_CONTEXT and MRB_GET_THREAD_CONTEXT macros due to access to mrb_context or any other fields that were contained into mrb_state structure.
GVL is acquired automatically when mrb_funcall, mrb_funcall_with_block, mrb_context_run and mrb_yield_with_class functions are called.

Changes

New APIs are added.

Thread
Mutex
GVL
Atomic operation

New mrbgems are added.

mruby-thread
mruby-pthread
mruby-win32-thread

Note

Implementation of Thread and Mutex API can be replaced by mrbgem.
mrb_thread_sleep API must relinquish the remainder of its time slice when it was called.
On Mac OS X, this change have not been tested.

How to build (for Linux)

Add new lines in your build_config.rb like below:
conf.gem 'mrbgems/mruby-thread'
conf.gem 'mrbgems/mruby-pthread'
conf.cc.defines << %w(MRB_USE_THREAD_API MRB_USE_MUTEX_API MRB_USE_GVL_API MRB_USE_ATOMIC_API)

run 'make && make test'

How to build (for Windows)

Add new lines in your build_config.rb like below:
conf.gem 'mrbgems/mruby-thread'
conf.gem 'mrbgems/mruby-win32-thread'
conf.cc.defines << %w(MRB_USE_THREAD_API MRB_USE_MUTEX_API MRB_USE_GVL_API MRB_USE_ATOMIC_API)

run 'make && make test'

All test passed with mruby-thread/mruby-pthread on Mac OSX10.10.

Hi @kyab,
Thank you!

@crimsonwoods why split mrb_state? You could just add a thread local context variable.

I think adding classical multi-threading is just not worth it. It makes a lot of things unreasonably harder, e.g. garbage collection, just-in-time compilation, code maintenance etc.
On top of that, a GIL just isn't a good solution. All major interpreters that have it try to get rid of it and once
it's there it's hard to get rid of it again. And beyond, GILs are terribly inefficient.
@crimsonwoods, I wonder what the actual problems are that you need multi-threading for, given that
for e.g. async IO there are much better solutions nowadays.
Anyways, having concurrency is obviously a nice thing. IMHO, however, the only good solution is
having something high-level, baked right into the language, so that the interpreter can, in a way,
"reason" about concurrency, i.e. knows when it might happen. There various models out there, actors, Go-style concurrency and others.
I personally think that (in Ruby) concurrency should be (pessimistically) decidable at parse-time, i.e. extend
syntax by adding e.g. a keyword for concurrency related actions and let the interpreter carry them
out. This clearly makes threading less flexible, but more predictable.
I think Python's PEP0492 is in some way related to this problem as well.


Infinite notifications take 2

Duplicate of #19, this time based on 2.5.0 and with considerations for -1/false value.

Awesome, great work @davecranwell.
Thank you for your contribution! 👍


resource

when resource is 'n_samples', the result may be not right. For the final performance sorting includes the results of small sample size.and In BaseSuccessiveHalving of sklearn, only the last iteration result is used when resource is 'n_samples'.
https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/model_selection/_search_successive_halving.py#L208

In BaseSuccessiveHalving of sklearn, only the last iteration result is used

Yeah, this indeed can be an issue. Would you be interested in opening a PR for this?

font{
    line-height: 1.6;
}
ul,ol{
    padding-left: 20px;
    list-style-position: inside;
}

        Yeah, I'll have a try with minimal code changes

On 10/13/2022 00:32，Antoni<EMAIL_ADDRESS>wrote：

Yeah, this indeed can be an issue. Would you be interested in opening a PR for this?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

font{
    line-height: 1.6;
}
ul,ol{
    padding-left: 20px;
    list-style-position: inside;
}

    I have opened a PR just now,   so you can check and merge them at your convenience and I look forward to seeing the new version released.

On 10/13/2022 00:32，Antoni<EMAIL_ADDRESS>wrote：

Yeah, this indeed can be an issue. Would you be interested in opening a PR for this?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

font{
    line-height: 1.6;
}
ul,ol{
    padding-left: 20px;
    list-style-position: inside;
}

Have you received my email? I have opened a PR

On 10/13/2022 00:32，Antoni<EMAIL_ADDRESS>wrote：

Yeah, this indeed can be an issue. Would you be interested in opening a PR for this?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Yes, I did - I'll merge it tomorrow, thank you a lot!


Build: Add Sonar PR decoration

Remove CodeCov.
Add Upload/Download coverage reports.
Use opencover format for SonarCloud.
Explicitly downgrade SonarScanner to version 8.0.1 due to this issue.

Needs to be merged before https://github.com/MudBlazor/MudBlazor/pull/9774.

Need to think about the coverage format.  I think this will break ReportGenerator coverage report.  Reportgenerator does support opencover I believe.  Need to make sure local coverage tools still work.  Also we may be able to remove the coverlet package in the main repo


Allow all valid discord handles

This fixes issue #6 to accept valid discord handles of at least 2 characters and with spaces.

I've tested this and it works! This also Closes #6


Trident 18020 - Get started with Cloud SIEM

Purpose of this pull request
This pull request (PR) does the following:

Adds a new section to the Cloud SIEM guide:
https://help.sumologic.com/docs/cse/get-started-with-cloud-siem/
Adds a new article (content taken from the Cloud SIEM Fundamentals self-paced course):
https://help.sumologic.com/docs/cse/get-started-with-cloud-siem/introduction-to-cloud-siem/
Rearranges topics in the Cloud SIEM guide

Issue number:

TRIDENT-18020
TRIDENT-13635

Select the type of change:

[ ] Minor Changes - Typos, formatting, slight revisions
[ ] Update Content - Revisions and updating sections
[x] New Content - New features, sections, pages, tutorials
[ ] Site and Tools - Updates, maintenance, and new packages for the site, Gatsby, React, etc

@kimsauce, could you review this pull request? It's a bit of monster. Let me know if you have any questions.

@kimsauce, could you review this pull request? It's a bit of a monster. Let me know if you have any questions.

on it!


Update PyTorch backend for the slideflow.model for Neptune sync

I was getting an error that the run instance of Neptune was duplicated in the parameters. This solved the problem when doing parameter optimization and Neptune enabled.

Thanks! I'll get this fixed.