.Net Foundation Design Reviews, 14 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitHub Quick Reviews

Description

Powered by Restream https://restream.io/

Issues Covered:
* dotnet/runtime 29932: JsonSerializer support for TimeSpan in 3.0?
https://github.com/dotnet/runtime/issues/29932
* dotnet/runtime 53539: Support DateOnly and TimeOnly in JsonSerializer
https://github.com/dotnet/runtime/issues/53539
* dotnet/runtime 1784: Writing raw JSON values when using Utf8JsonWriter
https://github.com/dotnet/runtime/issues/1784
* dotnet/runtime 53372: Minimalistic HTTP2 flow control API
https://github.com/dotnet/runtime/issues/53372
* dotnet/runtime 48702: Add a method consuming ReadOnlySpan to System.HashCode
https://github.com/dotnet/runtime/issues/48702

Chapters:
0:00:00 JsonSerializer support for TimeSpan in 3.0?
0:14:39 Support DateOnly and TimeOnly in JsonSerializer
0:36:26 Writing raw JSON values when using Utf8JsonWriter
1:37:53 Minimalistic HTTP2 flow control API
1:52:15 Add a method consuming ReadOnlySpan to System.HashCode

A

All right friends, we are live with another api review. um Today we have, I think, a few blocking issues on the json side, which apparently crystal things are the most important apis ever and then we have some http stuff and then whatever else is marked blocking, I guess, but the primary reason that I called this meeting on this day was uh because of the json stuff that uh leone wanted us to finish before lockdown tomorrow.

A

So I would suggest you start with this one just in that order, unless naomi wants to do it in a different order,.

B

I would do it in this order.

A

You would, or you would not.

B

I was thinking about it.

C

No, yes, let's do it. Please go ahead with this one.

B

Okay, uh so unless there are any objections, could we start with this issue? Yeah.

D

Absolutely I.

E

Just hit zoom in like twice.

B

Okay, uh so this is a an issue requesting adding support for time, span, serialization and visualization for system text json. If you scroll up a bit, uh you will see a link to the actual api proposal, um so that's it really we're not adding any apis. We're only exposing a time span converter for the benefit of the source generators. um So it is as simple as it seems uh from the api perspective.

F

Yeah this should have been an email we should have just auto approved at the book or email.

A

So basically, what does it mean for the regular json one? So does it mean that the time span converter is automatically available, or does it still mean? I have to manually? Add it.

B

So, for so for the classic serializer. That would be that we, we would be adding support out of the box for time span, serialization, uh which we currently don't do, uh but this particular api is exposed so that it can be consumed by the source by generating uh code.

B

If that was the question yeah, basically my question.

A

Was whether I have to do something to edit but you're, basically saying it's automatically in the json still has options in the converter right, so I don't have to add it. It just always works uh and remind me: do we normally expose the converters because you're not proposing you.

C

A

Converter or a time span, json converter type.

C

Yes, this is how.

A

C

Rest rest of them in the description data services class, so we already have uh approved api for like grid and all the other ones as well.

A

You know I didn't mean the property on this. On this type I mean like do: do we not normally expose the type itself like? Is there normally not a you know, a time span, converter type in the converter's namespace or something or do I misremember that we.

C

Have just a couple like the json string genome converter, but um but those are like for the advanced features to activate advanced features, but the rest of the like primitive converters. We don't expose them directly.

A

I see, and so how would I normally add or remove them. I can just find them by because I don't have a type to probe for then. How would I, I guess, they're generic.

C

A

You would do it by that right.

C

You could do um just since there's options to get converter for type. um That's the public way that we like have encouraged in the past, the ones that were shipping here for the search and generators so that we don't. um We don't root more code than we have to for the user's digitalization scenario.

A

That makes sense cool then, unless somebody has something to add. I think that looks good.

B

uh There is a question in the chat actually about back and forth problems.

A

Cool, I don't see anything in my set, but no what's the question on background on comeback.

B

So any any back, compat problems with changing the default format. So answering myself our general approach to um types that we don't support by default. Is we don't can they are technically a breaking change in the sense that you know? For example, if you serialize a you know a value tuple today it serializes as an empty object when we add support for value tuple serialization, the empty object will no longer be recognized, but we don't necessarily consider these types of changes as uh fundamentally.

G

Breaking if that makes sense, so I was reading the thread and there was an example of nullable time span being actually serialized into something. So it's not like we're adding support for a new type um and I'm I might be misreading the thread, but it looked like it. We did produce some output before no, I wouldn't think so.

B

G

B

Be missing: yeah! It's it's! um Okay! We! So uh I I have. I have.

C

Sorry bless you, oh.

B

H

I

Basically, if, if the sterilizer doesn't know about the type it treats it as a focal meaning, it serializes the public properties or fields in case of time span, there are some public properties, but it's not something that you can deserialize directly. So I I don't think yeah.

B

That example is.

I

B

Yeah that example in the chat shows precisely that, so it's basically dumping all the properties, all the derivative properties that exist in system.timespan. Technically, it would be a breaking change since we're moving away from that representation, but I don't think that should be an issue because we wouldn't be supporting visualization for that format. Anyways. So.

C

And to the to the general question of breaking changes like this: um if users really needed to old format pack, then they could add a converter that did the same thing that was done initially.

A

So for the for the source based generator, like I mean for the for the regular serializer I I would normally just remove the json converter of time spent from my options. If I don't want the new behavior, I mean, of course we haven't shipped source generation before, but let's pretend we would have done right. Let's say in.net core. You know five bishop, the json source generator. So how would I remove the the new time span converter for my source generator? How do I get back? The you know treated as a poco behavior from before.

C

You can add the custom converter for the type now and the search generator could honor that.

A

So where would I do that? I would put this on the type itself that the the generator generates into.

C

You could put it on the options like initialize an options instance and then just add the converter for time span.

C

A

So I thought um that when we do so, I thought that the options one was not visible to the generator, because that's only honored by runtime. Is that not true.

C

We have a mode that does annoy it. um I see.

C

Even the fastpass mode owns it as well, but you would be slower but yeah. We all know, like all the runtime options.

I

I I think, as part of this feature, we should add a little example to say: hey if this is actually breaking here's a sample converter that you can add and here's the one line of code to add to add it to the options.

J

K

What format is this using.

B

All right so good question: uh we had a interesting debate on that subject because a community member actually provided a pr initially for this and they actually chose the iso 8601 duration representation for it. But uh it turns out that that particular format isn't necessarily compatible with the timestamp representation. uh Iso 8601 duration uh represents relative uh sorry. It represents duration relative to a given point, whereas time span basically counting absolute number of ticks uh so especially on the serialization. It was problematic.

B

So after a bit of deliberation, we ended up on basically just serializing the to system.timespan.2string, more or less representation which is unique to net, but it's also what uh newtonsoft is doing by default and, more importantly, uh many common javascript libraries have now been recognizing this document format and uh it it it just works. So uh we'll be we'll be using that format.

K

But we don't need an option, so there's no there's no need for a public api to say which format I want it in.

B

uh No we're not exposing that option at this point. uh uh Obviously, if users want custom formats, the the proposed workaround would be to have users author, their own custom converters that use whatever format they place.

A

Can you quickly call out like what's the name of the.

B

Format, uh it's known as the dotnet format, but it's basically days colon hours, column, minutes, dot seconds or.

L

The you know second, decimal.

B

L

So eric to clarify is the output of the json serializer for time spans will be identical to one from unisoft correct, and would this converter also support deserialization correct, but only for that specific output format correct or is it more flexible.

B

uh There's no implementation as of yet, but the assumption is we'll be supporting that format. Obviously, we can discuss uh flexibility and we will be consulting the newton's of implementation as well. For that.

L

And so you, um when people were talking about backwards compatibility, so previously, I would imagine, because timestamp was being serialized as a poco. It probably was decentralized in a similar format as well. So now, when we let's say only support the serialized format for round tripping what happens to the uh behavior of all serialized timespan.

B

I would need to check, but I'd be surprised if the format we're outputting at the moment is round. Trippable uh steve might have comment on that, but we're basically treating it as a poco and dumping all the public properties and there's a substantial duplication of information there. um So my.

A

Own personal experience, I know it's not so. Basically, when you deserialize right now, you basically get back uh time spent zero. So you don't get.

B

An error you just you just.

A

Get zeros because we can't easily.

B

Yeah, that would be my guess, so from that perspective, I don't think we should be going down the path of you know supporting this.

A

Yeah I mean I mean- I think the interesting case that um we just talked about was if the client and the server are different right. If the server that says net and the client is javascript right, then you can have a case where the current format is actually being parsed by the client.

A

And so, if the server upgrades to dotnet 6, then you know we output a new system. uh Then the client is only able to parse that right. If client and server are both.net, then arguably it's not a breaking change, because you just make more things work.

A

But if the client and the server are speaking in different languages, then you know you might break the other side, but I think that that would be in the realm of like. Do. We think that's an acceptable breaking change, because I mean, I think, that's a general problem right. I think we want to be able to make more types serializable.

A

So if we would hold the line um that you know you, we can't do that. Then it would be. You know pretty impossible for us now. Everything would be an opt-in, basically right, which would be extremely ugly for people that you know start to see all this now. They have to say, you know, add converter x, add converter y, add converter, z right, that's that doesn't seem tenable in the long run.

L

I I agree with you: yeah makes sense.

L

By the way, just I'm curious I'm on my phone because you know teams has issues. um Are you able to hear me fine, yeah.

A

Actually, pretty good quality actually.

B

Okay thanks: I should be using the phone next time.

A

Right so, like I posted the comments in, I assume everybody is happy with what I said, because nobody was screaming at me.

A

A

All right, then, uh unless there's pushback I would just approve it as proposed.

B

uh For what it's worth, uh there's another proposal for uh date only on time only that is very, very related to this proposal, so it might make sense to do those in one go.

A

Yep that works for me. So then um let me just this is the I don't know how to get rid of this pop-up here teams, it's very annoying!

A

Oh here we go. No, it's finally going um so I guess this this one here right, yeah, that's.

B

A

E

This is why I don't like, when tabs talk into the window title bar, I guess.

B

So this proposal is pretty much identical to the previous one, but extending support for the new date only and time only types.

E

Has this package already had to have a ref split between net standard and net, really.

C

No, we don't want to do that.

E

Did date only in time only go is net standard, 2o.

B

No, I wouldn't think so.

E

So this will require that we now have to split the refs across the net standard version in the uh net six version.

B

Correct, uh I I'm not sure if we're shipping a net fibo uh version in in the next release, but we already have a net standard, 2.0 build and a net 5.0 build.

C

I see it's just be the first time converters don't have to be 601.

E

I'm just wondering if that showed up in the in the reference system, because once the reference assembly, assuming that it still ships with the reference assembly, I believe, all of eric st john's complicated, waterfall, graphs and things uh as long as the ref assembly is united. None of that matters the moment that the ref assembly splits now the universe, becomes a razor's edge away from imploding.

A

Yeah, we should definitely take a look at that. I'm I'm not entirely sure. I know what the rules are, but I believe this should be relatively straightforward, because in this case the package is the one to one with the platform package.

A

So in principle you can even update the platform package with that with a new version of the nougat package, but that we need to be careful with because.

E

Well, because this is the case where now, if something carries the the net standard implementation into a process running on net six, that now it can have lost this api. And that's when the runtime will crash.

M

So wouldn't it be possible to make these apis into extension methods over something like you know, serializer options, and then you could have the extension methods be distributed across different packages, so there would be daytime, then date, only converter and time only converter in you know, somewhere in in in the core, and then the uh the you know, portable nougat package would just have an extension method for time span.

K

Or we could source janet is the other option, because if this is only for source generation,.

A

Yeah, I assume these ones are not strictly speaking required right, they're, just an optimization, so we don't have to maintain the instance of ourselves right.

C

You mean the the converters themse. What do you mean.

A

So I assume, like you know you could just resolve the converter right.

A

But I think the idea is you don't want to right. So the idea is that there is a static one that you just know is there, so the source generator can just use that one rather than having to have some sort of lookup mechanism built into it.

C

A

C

Idea that it's statically referenceable for link for linking scenarios, but I guess we'll need to check if I mean one thing, is to check if the reference to those types is part of the compilation before trying to.

A

C

A

I mean this is the kind of catch-22 situation right. The other option we could do is we could just make date only and time only available for net standard two and then just have that reference from the nuget package, in which case you wouldn't have to split the reference assembly, and if that's something that we end up doing anyways, then it seems a bit backwards to.

A

You know build an extension method system here, because now we, you know, have more moving pieces. It seems, but it kind of depends on whether anybody once stayed only a time only, but given that these kind of types are exchanging in nature, I wouldn't be shocked if that eventually needs to be done anyway.

C

Do you reckon it's visible for netflix to ship with in standard those two types.

A

No, they they're they're brand new right, but we could put them in a new nuget package that target's net standard too right and oh.

C

A

And so basically, we would date only in time only in which case you know you can consume them from that standard.

E

Yeah for what it's worth, it looks like the this package doesn't currently uh ship the ref, but I think it builds the the ref for uh unified purposes and doesn't have a split.

K

Jeremy, do you have a link to the quote-unquote rules there or like the what to consider.

E

No um eric st john is the one who knows the most. Unless you know someone has surpassed him, I remember the risk, so the risk ends up being so jason, ship's inbox, but also as a package.

E

If you get a package library with a higher assembly version, then that will win in library unification as long as the depth file existed and the if the, if you've got the a version of the library that has less public surface area than something in the framework or that was referencing the you know, the net six split of the package could now have been talking about this type that no longer this member that no longer exists, so you'll get a missing member exception and that that kind of thing only happens as soon as you have a tfm split in your public surface area.

E

As long as you don't, then the worst that happens is the performance degrades, because, instead of getting that six optimized implementations of things using vector and complicated things, you end up getting the like the slow version using the net standard api and it's like. Well, that's fine. You pulled in this weird library. Your performance turned into what that library said to do, but public surface areas where it gets risky for semi-hoops.

E

But if the it shouldn't generally be a problem because that would require, I mean the problem would be if you did major version roll forward, which I don't remember, if we say, is completely unsupported or what these days, but that's where the risk comes in you built something for net five. You run it on net six. You had a reference to the version six of the package uh and now you've carried a downgraded version of the future forward.

A

A

I mean my question would be like to laomi it's like, so if we were to do what christoph suggested, which is you, instead of basically resolving them as properties, you could resolve them as a method call, in which case the user could provide them as well.

A

um Would we like that more than eric's suggestion of just emitting them, so you could imagine where you just say well, if I can find date only in time only or if date, only and time only is being used, but they don't. But but I can't find these properties, could you just emit a helper type that basically emits the entire converter, or do we think that's bad because now? Well, god forbid, you want to service those.

C

So we're meeting the date only and timely times types themselves.

A

Well, I mean you could sorry what you could do is the following right. You could say that the converter itself is public in the platform, so the idea is that if but well your case that doesn't help, because, because you are the platform right because yeah like the entire package, is who never mind so you yeah, I don't know what to do.

C

Yeah, I think it's the same problem like because the converters ought to reference the types and.

K

C

K

Json converter of date only and json converter of time only because if it was just json converter, then when you're not on 6o, you just return null or throw or something. Then you.

N

K

Split the ta, then you won't have to split your refs there's another option.

C

But even the implementation is based on like, if checks which will cause us to root some more things, not necessarily I mean the question.

K

No, no, you still have the same. The same public api, that's on the screen right now. You have that, except for you're dropping. What's in the angle brackets it's public static, json, converter data.

A

Yeah, like that.

K

Public static, json, converter, timeout time only converter.

A

I think the problem is it does it by us much because I feel like um yeah. Basically, if you do that, then you- you don't have to split in the reference to me, but you have to split in the implementation assembly right. So do you actually? Oh.

E

A

E

It better, I guess it's not well, it's it's better in the sense that you don't get a missing method exception. I guess it's worse in the sense that if it returns null then then you may uh crash out for different reasons.

A

Well, I think the problem is that in terms of like the package complexity, but you still have the same unification problems, because you still have to give the person effectively a 6-0 implementation assembly, if they're on 6-0 and a 541 when they are fifo and so on right. So they I'm not sure that would help us much in terms of we.

K

Already do that, though,.

A

Like we already have like.

K

Jeremy right, like jeremy, was talking about like when you're on net core. We we give you like the sim d optimized one.

A

K

When you're on net standard, we just fall back to the slow version.

E

K

E

So doing it as uh eric e's suggestion of basically nullable json converter, uh the non-generic form would like. We could even make that work in the complicated you got. The net standard version by it tries to do reflection once to load the type, um but to then ask for an intrinsic converter implementation or something but the, um but probably it would all have to have been excised, because you.

F

E

About the type so, but it would.

O

E

O

In the context of the discussions around wanting to be able to add a serialization support for a lot more types, whenever we decide here are we laying the groundwork for every single time we add serialization for another existing type in the future? We follow the same pattern. It feels like we're we're we added surface area, but then we're not able to use it.

E

The the problem is, what does the net standard 2 implementation.

F

I get the problem.

O

But we we added the generic version for a reason.

E

But now we're saying we can't use it in public surface area because of all these other strengths for types that don't exist in the net standard. 2O type closure correct, yeah, rather.

A

E

That standard, 2o, tfm type closure.

A

But that seems to be pretty well.

E

E

So time span is: is part of net standard 2o, which is why the previous one worked and didn't have these additional questions. So we were able to add that one and say it was not a problem. It's this one is where we hit the new hurdle, there's a bird that your microphone is preferring over you. So I'm interpreting what your question was. I may have missed it.

A

Yeah I mean I, I think that from an api standpoint, I think it is unfortunate. I mean I'm not entirely sure how to solve it, um because I mean you either have a story where the source generator can just emit stuff. If things are missing, but fundamentally it still means there needs to be some sort of implementation that that the converter can rely on for the source chain, which either means we put the implementation into the user code or we call into the platform code, but that by definition, requires public api surface right.

A

So it's I'm not entirely sure how we can avoid that.

A

So I think to me kind of in terms of api approval. I think this seems fine. I think the general idea that our converter can or that the rtls can natively support data only in time only given. If we just added those types for six, oh, it seems completely reasonable.

A

I think to me the only thing that gives me a pause is the openness of that. So what I would prefer, if leonik, can take this back to the drawing board and said okay, which of the following three options. Should we do? Should we say that we only serialize types right now that are part of netstandard two, in which case you would say yep unless date, only time only will nets to be witness center. Two, we just don't add those properties, in which case the question becomes.

A

How can we light them up, or do we not light them up at all, and I think for that, the only two options I heard was we either source generate them into the user code or we find a way to expose something in the public api surface that doesn't talk about data only in time only.

A

Which you could imagine a generic method that gives you back a json converter of t right and you literally ask it for a t, but, and then the implementation isn't obvious, you know if type of t equals blah return, and this way you can basically return your back a generic converter without having to talk about the type in the api surface.

C

Yeah, I think it's a good question to go back and think about, um and then you know the primary like the existing json star as a behavior doesn't need the api, um so users will be unblocked by that and then searching can come back with its own concentrations.

I

Right yeah, I think, for the source generator. Unless we try to solve this differently outside of the source generator, it would just cast right to the um date only or time only it would cast a dc converter based class to the t version when it needs to use it.

E

Yeah, I mean roll forward the fact that the net standard implementation wouldn't have a converter, for this makes it diff like. If you get the complicated you got the net standard on net six, then you'll still lose the functionality. I don't think that there's a fix for that. um The.

E

Yeah kristoff's suggestion of a higher level assembly that adds more of the just exposes more of the built-in converters um helps a little bit and that it solves the public surface problem, but the runtime problem would still exist.

M

But I don't understand the runtime problem, because if I'm using net standard 2, I don't have data only or time only so. Therefore, I don't care whether you have data data right yeah. So this advice.

E

Yeah, so the the best concrete example that I'm coming up with- and this is just off of cobwebs of my mind- is you build a net five application so date only and time only don't exist.

E

uh You do major version roll forward to get net six um and you had it or when you built your application, you had a reference to the net six version of system text json uh the best version for your library doesn't know about data. Only in time only your assembly version, um I guess, would actually tie so. We need to skip another version.

E

There has to be seven but anyway, let's just say your local copy wins when you do major version roll forward, if anything in the framework or any other library you're talking to uh already in the shared framework, talked about json serializing data only or time only that's going to fail now, they're, either going to get null from this converter or the member doesn't exist or whatever. So it's not your application directly will break it's some component.

E

Your application is, depending on dependent on this functionality, that's no longer present or reference the member and gets a type or member exception. Okay,.

L

E

A lot of complicated steps, but it's a thing: we've tried avoiding the problem with the semi-ubs before.

M

Yeah, maybe there's something I just don't understand how an existing application that didn't have data only suddenly run into trouble serializing data only because it's not only the application was not using it. Presumably there is no data you know flowing around that is date on the data.

E

uh It'd be like if you're a web application and asp.net core has added some logging that added a date only in their logging and they're, using json or the json formatter.

E

For that, then, because you upgraded the behind the scenes, logging has been upgraded and now that fails because it doesn't know what a date only is in the serializer.

A

I mean I mean I think kristoff has a point in the sense that if you look from a source generator standpoint, you can only emit sources for the things that you statically can reference right. So if, if you're building against net standard two, you cannot statically depend on something that is date only or time only because these types don't exist for net standard two.

A

So the only case where you could ca, you know get into a situation where at run time you want to serialize the type that happens to have a date only yeah you may be building against net standard two, but then the thing you're, depending on, has a custom asset for net standard. Six that happens to have a property of type data only in time. Only, but in this case these converters are not used right, because now you fall back to what does the json options?

A

Instance have a converter for data only in time one and the answer would be yes right.

E

Right, but if, if you know this, mythicalasp.net logging component itself use the source generator, it's going to reference these properties, which are either going to not exist or return null.

A

Well, I mean, but they would build against the net 6 version of the of the json implementation, in which case they would give you back valid values right right,.

E

That's why this requires. I think it requires major version rule forward and if we've decided that we absolutely don't care when that happens, then I don't think we have a problem. uh There may have been other cases in right. Eric's data flow diagram, but that's the only one that I remember.

A

Yeah, so that's kind of the thing where you know: I'm not sure that that's bad yet, but I mean I've seen it bad in the past. So that's kind of why I said like do we like the complexity, um but I mean in in chat somebody else brought up sql client right, so you could imagine. Secret client wants to use data only in time only and at which point we might actually just end up better off.

A

Just um you know, making those types available as net standard two, in which case the whole complexity implodes very quickly, and it's very simple at that point.

A

It's just yet another package.

J

A

All right, so then, how about I just mark this as needs work, so that we can just think through the upness of these things. But I think in general I think it makes sense, but the reason why I think it needs work is because we have to figure out what to do with the not net standard. Two.

A

Types, if that makes sense,.

E

Yeah then, I recommend syncing up with eric st john and seeing if we have the semi-ub concerns written down somewhere, so that we can make sure that we best understand them.

C

Thanks, thank you.

A

Okay, let me just put that here all right: uh writing raw json videos when using utf-8, json writer.

L

So sorry, emo, can you go back to the timestamp issue? um I was reading through your comment and there was a, I think, a correction that should be made. uh You had mentioned that if you want or if you don't want the new behavior, then you can manually remove the time stamp from the decentralized options. uh Disasterized options are invaluable, you can't remove them and the list of converters is internal. The solution is to add your own custom time stamp converter, not removing anything.

L

You might want to make sure you fix that. I I I did it. I asked leo me and steve in the chat about this just to confirm.

A

Okay, what does that mean like I? If so, if I want basically everything except, I don't want to serialize time spans, I have to basically register my own time span converter, that does the old behavior.

L

Yes, so you would the way you would want to customize the conversion of timestamp timespan is to add your own converter. There's no there's no consider removing converters either you get the inbox behavior or if you want to override that behavior, you add your own.

A

Interesting much work is that together.

J

Behavior, because.

A

I mean do I now have to re-implement the poco style serializer.

C

You you do, but I don't know if people, because it's not roundtrip, so I'm sure people are already registering their own converters rather than depending on our old stuff.

A

Right, it's more like the scenario that I said where you have like client and server written in different languages right, so you imagine, you have a you have you know, react native client and then your server happens to be net right, and so the client is no longer working right. Like long tripping.

C

A

When client and server both.net right.

C

Okay, yeah: we it's a suck to have to write a sample for this, but we can.

L

I would say that is going to be very rare, uh very unlikely that someone would want the old behavior, um but if somebody does it should be yeah. We could write the converter for it.

A

So, like I I feel like if we have a built-in one that just gives you back the pokestars and it's a one line. I think it's fine. If it's like copy this 400 line sample code into your application, I think we reach the threshold where that's not really a workaround anymore right or not one, that we can, with a straight phase, recommend to a customer right.

L

Right, but we could we could use customer feedback to drive that decision right. I don't know if you should do the preemptive.

A

Well, yes, and no right, because the problem is when so for breaking changes at the time you get the customer feedback, you're kind of screwed. If you work around this wait for the next version, uh but uh so in that sense I would say.

C

If you break people, you.

A

Should have a preemptive story that is kind of like add this one line of code or set this one compact switch or something right so that when, when the it doesn't have to be like, you know, super convenient, but it should also be something that you know. If a big customer comes, we can tell them of a straight face. Here's the you know, maybe it's three lines of code right, but uh like something that is reasonable in complexity,.

L

While we are in preview, can we do some research to figure out if this is actually even something that's worth investigating.

A

Right now, right so like the amount of feedback we are getting and the amount of reaction time we have left is is very small. So if this were preview, two or something I would agree with you, but I think we are pretty late for these kind of things yeah. I.

E

Feel like this is going to come in at like 20 lines of code, which feels within a copy paste threshold. To me.

A

Yeah, I kind of agree, but is that very.

H

Easy and specific.

A

For time span, or is it? Is that a generic thing that we could also use for any other type, that we add support for later.

C

It depends on your type.

E

My thinking was for time span of just like. What's the number of properties it has, so you say to write them out. Yeah.

A

E

A

It seems almost like if.

C

We had a generic.

A

Poco sterilizer that you can just register and say you know, add time time you know, let's say time span and then you say new generic poco to laser and that I think it would be a fine workaround, because then we could say it's always the same, no matter the type, and we write this thing once and you know it obviously works right, but we don't have to do this for this one type.

A

I just think we should think about what that would be, because this is not going to be the last type that ships in the framework that we had civilization support for after we should.

P

I agree you know, and the other thing I'd point out is that we can it's absolutely possible to build a generic thing, because we know the types that we've changed right so anytime. We change a type so that its behavior is different than before. Even if we just need to special cases in the generic one, we can do that, and somebody just needs to plug that in and it'll work right.

C

So yeah we'll spend some time thinking about a generic solution for some. What for this problem.

I

I think it's very unlikely people are taking any kind of dependency on it.

B

Yeah I mean you can't.

I

Run trip and then the properties are going to be. um You know days minutes seconds. Colon expresses an object, so what people have been doing is implementing their own converter through a couple of steps that are floating around and once we provide the official implementation, they will just remove their probably remove their own converter unless they have saved json or something assuming it doesn't align with what we're doing.

I

Otherwise they would just remove it if it aligns. Well, I don't think we have to do anything other than publish the samples. Let's say this is what the old converter did: there's yeah five lines of code 10 lines of.

P

I

P

I think you should also consider that it maybe.net.net, but different versions of net.

J

E

Yeah, I think it, I think, if you add the api of you, know, default property, converter of t um or whatever, and that that just eliminates this debate next time, it's like how hard is it? Well, you just say: time span goes to default. Property converter of time span done.

A

Yeah I mean like think of a different scenario, I think of something that somebody like office right office graph or somebody they shipped an api somewhere in that api. They happen to return a time span. They never really tested it. They shipped it right and but it was public for like let's say two years right. Is it inconceivable that some of their customers calling their apis wrote custom code to theolas the time span? Back?

A

Absolutely it's a workaround right, you call office apis, you want to use them and the way they emitted them was by just poker studios in the time span. So you changed your code to handle that. Well now they happen to upgrade to.net six. Well now the time span is being serialized as a time span. Now the custom converter that the customer on the other end wrote, stops working right, and so I think, if the is it is it very likely? Well, it's not necessarily very likely.

A

If you talk about you know a normal style, uh you know civilization, but if the customer is big enough, it can be bad right and then it's really unfortunate. The workaround is, like you know, several hundred lines of code. If it's like you know, this is one type that we shipped that always provides to the the poker star civilization. It seems pretty trivial for them to to add that if they wanted to right.

A

um So I think that to me, the thing with breaking changes is even if they're unlikely you want some either convince yourself that it's unreasonable for people to do this work around or you convince yourself that the workforce is easy enough and repeatable enough to be okay with that and I think for civilization. We know that people depend on the stuff and we know that people upgrade versions independently between client and servers, and so I think we should you know, because we want to be able to add new support for new types or existing types.

A

I think we we would want to have a very easy story to tell people like yeah. If you happen to depend on the old behavior. Here's the one line thing you can do, because otherwise, if it's a one-off for every single release and it's a one-off sealer for every single release that you have to copy and paste into your code, I think that might haunt us eventually.

L

P

I was gonna say I actually the more. I think about this, the more. I think we should seriously consider not changing the default, not breaking anything here, because it is going to break somebody right. Somebody is going to hit this and go wait a second, even if it's just as dumb as like, like somebody may have a date time and they put it in their jason and they serialized them. They said. Oh, this is how dot net serializes the date time great.

P

I can write my python code on the other side that just you know, grabs whatever it's formatted as um uh somebody's gonna hit this and it's gonna break them, and it's it's really, as emo said. I think part of the question here is um how easy is it to fix for the folks who are broken and we need to make sure that it is easy to fix right.

P

Second of all, the other question is how many folks are going to be broken, because if it's not a very small number of people who are broken, then we shouldn't be doing it.

J

B

For what it's worth, this has been our standard approach, when extending uh support for new types like one example would be icy enumerable, which so far has been serialized as an empty json object. uh We changed that and that would technically be a breaking change if customers depended on, you know, asynchronous being serialized as empty objects,.

C

Yeah, just my limited experience so far is that every time we've changed the behavior to be what most people consider correct like I've, never seen somebody come back and say I've broken like we did, that for key value, pair civilization, last release like I'm not advocating for like making breaking changes, but I think this is correct enough for it's not to be a big problem and some of the other strategies that we've talked about can help.

I

Yeah I agree I haven't had to write code to opt into the correct quote-unquote, correct, behavior broke my opinion.

C

I

Ultimately, what we should have done in you know version three or you know of network which is version of the serializer. We should have said hey, we don't have time to do. Time span just throw not supported exception or we didn't know what to what what format just realized. It's not enough time, um but.

C

We didn't do that.

I

And we did do that with all you sync innumerable as eric pointed out, um so it's both basically you're serializing garbage right and if somebody's taking dependency on that garbage, um it's a bug and we're fixing them so.

P

I think there's a difference between serializing, nothing or garbage, which is useless versus serializing, something that is useful, which it seems like what is what we're doing with time span today. Even if it's not ideal, it's still usable right right.

L

I would push back a little bit on that. I don't think the current civilization of timestamp is very useful at all. That's that I think that's where the concern is in general, the principle I agree with you jeff uh jeffrey, that uh we don't want to break serialization output, but in this case our like, I think what leo me and steve are saying. I don't know if anybody would ever in realistically want to take a dependency on that output, that we have it's almost equivalent to throw not support exceptions.

A

Well, yeah, but if, if somebody can actually write code that does sterilize it correctly, then you know there's a you know you can make it work kind of thing right. So if you.

C

A

Just I'll put empty like what we did for icing and new mobile, in which case yeah, that's actually the equivalent of throwing in a platform not supported exception versus in this case, we just I'll put it in a shape that we don't like, but it's something I could deciolise back. If I wanted to, the question is like I think I think it's okay for us to say the way we shipped on our core now and the way we approach things that we do accept this as a as a fact of life.

J

Somebody is really loud.

A

I don't know who it was but, like somebody was in a truck somewhere, so basically I think it's okay to say: if we, if we uh you know given how we ship and given our bar moving forward. This is one of those changes that we just want to be able to make. I think that's reasonable. I think it's okay to say the amount of people that are broken by this.

A

We expect to be low, but I think we need to have a story where we can say: okay, if you're affected by this, do this and yeah.

A

If it's 20 lines of code that we copy and paste, that's fine, I'm just wondering do we want to be in a world where every single release, when we add a new type, we provide a different set of 30 lines of code, or are we investing the time once to build this generic converter and say that's the one you register for whatever new types you were impacted by and I think that seems to me a scalable proposition. Then we can say here's the work around. It's always the same.

A

Here's our bar- and we just want to make more stuff work over time and, if you're impacted by this well too bad. But here's what you do.

L

That makes a lot of sense. Should we then track it with a separate issue of the whole default converter of t that will approach, and that would be the next item for this one. I think.

C

That would be good having the talking board.

A

I think that's no okay,.

L

Eric or liam you probably have something you want to add.

C

No, I just wanted to say that eric had the api proposal in the chat, which I think would be like the general solution here, because that's the serializers fallback for all types just to use the object converter.

C

So if we had an api to create an object converter for all for any type, then people effectively get back like backward, compatible logic, yep.

A

That seems reasonable to me as long as we have a way to do it once and for any type. I think that's that's great.

A

All right anything else to add to this, or should we move on to the other one.

A

Okay, then, let's go to this writing raw json videos when using utf.jsonrider.

C

Okay, um so there's some there's some scenarios where customers want to write existing raw json uh payloads when writing new payloads with the writer.

C

A few reasons could be to you know, write to rogerson quickly, with or without validation, um evade our escaping logic when writing with the writer serializer or to write invalid json. So those are some common scenarios. We have a workaround today with json documents, um so the ideas you pass past the payload and then we have the conv a helper.

F

C

F

C

Writes to a writer, um this implementation will build a metadata database for navigating the document, which is not necessary, given what the desired functionality is and has some purple. Red um and jeremy will know that.

C

I can provide my information there, but um the goal of the future is to provide a performance apis to write your projects and values, depending on your scenario and how much validation you need so for api proposal uh proposed three methods taking different data types, um so we only spawn of bytes for the adjacent optional parameter to see whether you want to skip validation defaults to be forced validate by default, um and this is just the that influence is just checking the structural uh content of the json.

C

So things like node, um two double uh braces in a row um that the nesting level will be the same when you start and stop writing um it's basically, just making sure the reader will be able to read it back on the serialization without throwing. um So that's the violation. We do that um so jumping into some scenarios below um let's go a little bit down.

C

I understand questions so far.

C

Okay, some scenarios uh should we validate raw values for structural characters, um so I'm proposing that we do that by default. Just because system technician cares about things being correct or safe, rfc compliant um and then for performance users might not want to do that because they trust their data or they trust the data and just want to write that so give you an option to skip it.

C

Should we encode the raw gcm payload according to the writer options, um so in summary, like we, don't I'm not propos, so I'm not proposing that we do that now, but can provide an option to do it in the future because, primarily because nobody has asked for it- and this is a high performance api request and um if you really care about things being encoded properly, you skip properly we'll do it beforehand before calling the api and um another question is: should we reformat the payload, according to the writer options, to permitting the influences, that is the rights indented?

C

uh There might be some much space changes if we were to reformat it to online, um but again nobody's really asking for this, and um you know you just want to write it json does this and we can provide functionality to do it in future. um So, ultimately, like all these questions depend on scenario. What users want to do puzzle um wants all of this to be fully configurable, but we're only starting out with the limited set of things that people want us to do or have have required.

C

um So, let's bring in a bit down to some concrete scenarios. I have a blob which rep, which I think represents json content, and I want to envelope. I want to make sure that the envelope and its inner contents remain well formed, so consider perhaps the azure sticky team who who write service protocols and part of the json they're. Writing is internal. What's called information and another part is a nested.

C

This technology synthesis are provided data so when they serialize this, they most likely care about the json being structurally violated and overall below this valid from their from the requests. um Don't care about coding or want to reformat the json, so um our default call to the right value would validate um and do nothing else, just validate that json structurally makes sense and then just write it to the destination buffer.

C

um So I have an example of what that code might look like. um So I'm just scrolling down a bit more yeah.

C

uh So yeah the line, the comment just use, the actual api calls.

C

So actually, I think preceding that you will want to write the property name. uh I skipped a line there, all right. Oh okay, I did I didn't check so yeah. So this is what the api calls look like. um So that's one scenario.

C

So moving on to the next scenario, I have a deliberate sequence of fights. I have a.

K

Quick question: I have a quick question on the lines that are highlighted like is it expected that the raw value has the colon after the after data.

C

No, it's not it's supposed to it's. No. This.

K

C

A great property name.

K

Includes includes the colon.

C

You could include the color, so this is just supposed to be a complete json value which can be written as a property value. It can be written as like. A root object can be written as a collec, uh innumerable like dictationary element or a dictionary.

K

C

Common question.

K

I can't do partial things even with a non-validated case.

C

Yes, well, we do not validate the case, you can do it whatever you like, um which director already allows you to to write garbage without validation,.

M

C

M

That the column is written because that's how we have this existing api right property name. But what about the comma? After when I write a property and then row value who writes who's responsible for writing the comma before the next property.

C

You serialize the right comma, because if you're writing another property after then like write property name again, it knows the writer knows what state it's in or what state it's assumed to be in based on your validation of um settings.

C

So the series the writer handles that I see so so uh user is not expected to write, trailing, commands anything or worry about how it's being composed just write, a complete json document and write out address.

M

And one more one.

C

M

Krista, okay, uh and so, if it's a property, I understand you would write the comma just like you expect explained what about if it's items in an array, so I open an array and then I want to write items as row values. Do I have to put the commas or not.

C

M

How do you know when one value ended and the other one starts.

C

We're requiring for you to write just a single json element, so the writer knows when you write stat array, I'm writing an array of things and keeps track of where it is so once you finish, writing with validation, like you of course know that it's correct without validation, it just would write like. If you write another array element and not the end array uh token, then it will attach a command between the element values. I mean the array value so.

L

C

L

I I can probably help a little bit answer as well. The next method call is the one that's responsible for adding the comma, depending on the state.

M

Yeah, I think I now understood something that I was not before aware. The row value is not really completely wrong. It has to represent whole value. For example, I cannot just write partial, like open a bracket, some properties of an object, then in some other piece of code right the end of the object. Basically, when I call rob a write row value, it has to be syntactically valid by adjacent value. It cannot be partial, json value yeah. I think that's.

B

And that's why we're calling it right row value instead of right row, jason, yeah, yeah,.

M

Okay, I I think that's that's fine, um like I think initially, my mental model was that it's literally the writer doesn't care what I write I can you know like if I want to write an integer, 1, 2, 3 or 123, I can I I initially assumed I can say, write row. One write row two write row. Three. I can do whatever I want and then I basically when I'm done, you know the the writer continues, but that's not the case. It has to be a valid like in one atomic right the whole value.

M

I think that's fine.

M

Okay, um I mean that's the.

A

Only way to compose it right because otherwise the reader would no longer know otherwise, I wouldn't know, I know which state is in right. You basically yeah.

M

A

M

Yeah wonder interpretation of raw is just you can write whatever you want. As long as, and you know, the color of the nitro value is responsible for making sure that it ends in a consistent place.

M

That could be that's the semantic right, but I I think this one is good enough and it's much simpler to reason about. What's going on.

A

I think it's also safer. I think if we go with the you know literally raw text, then I think this would be a major hole with people hanging themselves very quickly.

C

Yeah, okay- um and the second scenario here is just I have like- I know, specific bytes. I want to write, and I know what I'm doing so. I don't need to validate the logic, because I want it to be as fast as possible, like I'm writing some numbers in a different format and what the writer would write as the example here. um So that way you can skip validation, so you just scroll down and then you can see method call where you pass this validation volume, and so that's what the user's code could look like.

A

Do we think that people want the like? I mean how often do you have cases where you don't want the property name.

C

um Events yeah, it depends on the blobs like what they are. I mean, I think the scenarios where you could want to write the property name and a simple value. At the same time, just like we have right number right, string versus right, number value and right string value, um but again it's just like we can just add it as required as needed.

G

I think there is a scenario like an array of customer payloads.

G

Where you don't want property names and it follows the pattern of every other write method. So it's kind of nice.

C

Oh wait was the question from emo whether it's like just values of properties and like values is definitely like, I think, more important to to add up front versus.

A

Yeah, I was thinking like if, if you almost always have code that looks.

L

uh You you don't email, you don't always have code like that.

A

L

A

It right but like if you're basically saying you also need it for a race and for other things, in which case you need the ability to just dump some raw value into it. I think that's fair.

C

It's just the examples here.

M

Yeah, so the question I another question I have is in the github issue: uh you also have this json right raw options, and here we are discussing the boolean to just turn out the validation which api is the current proposal. Do we want the options or we just want the boolean.

C

Yeah I started off so I started off with something that looked like this, where we just just a boolean with the validate and it's the three core questions like do we want to validate, do we want to encode?

C

Do we want to run the specified encoder and do we want to um the last one of reformat to jason payload, and I think the answer is, and this proposal is saying that those are not like the answer to those is we only validation is the thing that most people like care about not really wanting to encode values like if they wanted, like encoding, how the performance hit, and I think the scenarios are just mostly around the movies we've seen that mostly around just validation, um but we can take a look at the proposed api to see what that looks.

C

Like just a question of the relevance um and whether I want to surface those options, we can still provide functionality to support them in the future if they are really required, but it just means adding new overloads to these methods that take additional booleans, so say: hey. Do we do this, or do that? um I think that that approach is preferred, or is what I'm standing behind more solidly.

K

And the motivation here is performance right, like the reason we're adding. This method is because we want faster performance.

G

Not only the other thing that we sometimes care about is not messing with customers input, for example, cosmos db when it stores customers documents, it doesn't try to reprimand them or touch them in any way, like the exact formatting that you send it in is the exact formatting you get. So this is the the other factor for this feature.

M

Yeah, I think eric was saying this is the current behavior and the options, the more complicated options lets you do some level of free formatting and then it maybe doesn't make sense, because the moment you do reformatting, why do you care about this real value? In the first place?.

C

Is that yeah? If you do care about those two things like formatting and coding, then you could use the workaround, which does that to the end. She'll have similar prof, perfect.

M

I mean the only thing I would say to this is the workaround is kind of not very intuitive and a bit ugly. So if we do believe that there are people who kind of have whole json, they don't want to kind of. You know, write it by writing. Json.

M

You know elements one by one, but they do want reformatting. um Yes, we have a work around, but the workaround. As I said it's, it's not very intuitive, like somebody has to read a guide. How to do it. Nah, you know like it could be a useful feature, but maybe we don't care.

L

It's two lines.

M

Of code crystal yeah, but it's not that it's two lines of code: it's that that it's not super intuitive and by the way, how is two lines of code you need to like? Basically pass the payload.

L

I share the two lines in chat: it's uh using var, dot equals json, document.parse, dot, root, element or write to writer yeah. I said fine yeah.

M

Maybe it's two lines: if you put lots of things in one line.

E

So levi, how do you feel about the writer being in escape everything? That's not latin mode being past non-latin text.

F

uh So given given the particular scenarios that were being called out for this feature, um I I spoke with leone last week. I didn't think it was all that important, um because the big scenario seemed to be uh take, take this data and represent it with as much fidelity as you possibly can when you're doing something like enveloping it.

F

um I I did express concerns both last week and in chat uh in our internal chat that I think it might be a little bit too easy for people to believe that they can turn off validation um when they really shouldn't have done so, um but escaping like yeah. Given the scenarios, I I don't, I don't see people running truly untrusted inputs through this api.

E

Fair enough.

A

And you say that because it takes a read-only span of bytes, so you don't readily have the data available, anyways or.

F

It's I I say that, because again, just just the scenarios that laomi read to me last week seemed like they wouldn't necessarily benefit from us doing a whole lot of post-processing on the payload um as written in the document here there are. There are two big scenarios. The the easy scenario is like. I literally just have these raw bytes that I want to write on the wire right. um Like you, you gave me the raw bytes to write on the wire have at it.

F

Like you told me to write these bytes, I'm not going to post process um the other one, uh and this is, I think, what's important for things like azure uh cosmos. So on is I have this object that the user gave me and I want to put it inside of an envelope, and I want to send that entire envelope, along with the inner contents onto some backend somewhere.

F

At that point, we're really talking about like a proper service api. um The only thing that to me really matters there is that the inner object is absolutely well formed, json on its own. That means rfc compliant no comments, no trailing commas, um uh well-formed, utf-8 and so on, which, by the way the normal utf-8 jason reader will not check all of those on your behalf levi.

F

Why do you care about the inner object, not having comments, because if the inner object has comments, um it could actually cause an envelope escape like the when, when the back end goes to process the entire envelope, uh because json is structured data rather than something like a tag or a tag, prefixed uh value or a length prefix value. If you have a stray comment marker somewhere in the inner payload, when the back-end's going to read it, how do they know when the comment ends? Like will? The comment start escaping parts of the envelope itself?

F

Is the back end now treating user data as the envelope and now misinterpreting things like authentication, headers and so on. I'm.

M

I still don't understand because the backend starts processing the comment. It either understands the comment, syntax or it doesn't, and if it doesn't, then it immediately fails and if it does, then it should know where the comment ends. How does it know where the comment ends?

M

Well, what's this, what's the comment syntax in in json, there is no there is there isn't one.

Q

Well but the extent of.

F

Json that supports comments. So there are, there are two traditional ways to extend json with comments. One of them is slash, slash, uh which goes until you've hit a new line, but did this system introduce a new line after where you said right? Raw object? um Another way is to use the slash star syntax.

F

Well, did the inner payload have a star slash to end it like? If neither of those has taken place? The comet's going to extend into whatever part of the envelope occurs after the inner object.

A

It's basically similar to a sql injection attack right. They, you.

F

Yeah, it's it's exactly equivalent to your sql injection.

M

Interestingly, can't you do the same, can you cause the same problems with you know not even using comments just keep closing brackets till you escape the envelope.

F

Yes, which is why validation needs to be turned on by default, if you're doing some type of um some type of uh enveloping.

Q

Mechanism: okay,.

M

So it's by default, it's on, but the the color of this api can turn it off and when they turn it off. You accept comments. Correct is, is that.

L

Yeah, when you turn it off all, basically everything can go through. Okay, yes,.

F

Yeah, when you turn it off, I think it just goes into a raw bytes node right.

Q

Okay, I think what, basically, what you are saying is when.

M

The validation is on. We don't accept comments. If you want comments, you have to turn it off.

M

That's it that'll.

C

Be the behavior.

F

Yeah, I the the way that I would see this is, if you, if you say, validation off like you, are basically signing in blood that that is well-formed jason um from the perspective of your back end, and you know how to handle it. Okay,.

E

And even if you know it's well formed, you better have hoped and checked that the uh slash slash at the end of the line ended in a new line and not just in defile, which is a legal interpretation of a trailing jason comment. Yeah, but.

F

Yeah, when I say in blood, I don't just mean well-formed, I mean trusted every single bite of that is trusted. Indeed,.

A

So if so, the json writer doesn't have a configuration for accepting comments right. That's part of the serializer right.

L

No, it has an api. You can write comments directly by calling it.

A

L

There's no writer.

A

Options right, so we so inside this method. We wouldn't know whether the caller is okay with comments or not just based on some ambient configuration state right.

C

We we wouldn't know that now, but if we added api to do it, then I'm not sure if I don't think it'd be a breaking change to honor that if we like, because you would have updated it, so we can honor it. If we do add something saying like allow and reader say that, allow comments.

L

What is your question again, yeah.

A

Basically, my question is more like. If so, if we currently have, let's say some configuration for the writer that says, I'm okay with comments, it would feel odd to say if I leave validation on that, even though I said elsewhere that I'm okay with comments that this api would now throw. If we don't have that.

L

I think it's okay, but we don't have it yeah.

A

F

Yeah and maybe in that world, you strip the comment before you write it in as part of the inner content. Like I don't know,.

A

You being the caller or you being the implementation of right.

F

The implementation of right raw value, okay,.

E

Yeah, well I mean that one would then be doing particle read particle rate, which uh would be the reformatting, etc.

E

Because I think that yeah, the the suggestion is that it just gets, you know, runs the reader, your default reader over it and if it hits no validation errors, then it goes like great now. Blit the bytes.

E

So you'll end up with a if you're, a pretty printed writer and you get a compact json, then yep you have some compact in the middle uh or vice versa, and it's because you said, write it raw. So I wrote it wrong.

F

Yeah and stuff like that, like for from from my you know, wearing my security head, I don't necessarily have a preference one way or another, like the the jason team will, will make their own determination as to what the appropriate behavior is. There.

L

So I kind of like this api. I, like its simplicity. I am also okay, with the alternate design that naomi had posed, which was for extensibility, if you ever want to. In the future, add a json write raw options which allows us to split apart this validation from validation and encoding, and things like that. I did have one concern, though: around naming of the parameter, because we have a global json writer options called skip, validation and all that does is structural validation and never input validation.

L

We are overloading that term a little bit with the subtle change here to mean skip addition is talking about the actual input parameter itself. So maybe we call this boolean skip input, validation or something like that, because there's actually a solid difference, adjacent writer options, skip validation is only talking about structural validation. So, for example, if you do um start array followed by an object that will fail.

L

But in this case they're talking about is the json value that the user is providing into the parameter, a complete single value json and it's well-formed, and it's not talking about the state of the writer. That's in so I would imagine most people would want to keep skip validation on the json writer options on in debug, so they make sure they understand that their code is written correctly and then they turn it off and release and that's what we do in serializer, but the skip validation boolean in the right row.

L

Value would always remain on because you're talking about runtime input data that might change. So we may want to rename it a little bit differently at the parameter name.

F

That is, that is actually a good point yeah, because the you you're right that the structural checking that normally takes place is to catch uh coder errors, whereas this is to catch input, errors.

L

Perfectly put levi, I agree. Thank you exactly.

A

So what is the suggestion, then, for the api.

L

Maybe skip input, validation or you know, I'm open to whatever people have ideas. I see.

R

R

L

And last thing I'll say from being a conservative side of things, um since this is mainly about performance and an escape hatch. Maybe we do not make uh the string and char just ross star overlords, available or preemptively, and we only have the lost byte ones unless we see our need for it because again, if this performs this mainstream performance and an escape hatch, why does the customer have a json string? I mean utf-16 string.

F

You could imagine um there was a scenario that was posited earlier about doing custom formats for things like daytime. You could imagine that if somebody was inspired to do an interpolated string, builder overload or extension method on this, they could go to a temporary raj char buffer and then uh and then send that through conversion and then over across the wire.

L

Okay, that seems usable, so I guess the roster was there because of that reason, and we want string because sometimes some languages and some platforms don't support reasonable, really span. So we just want that for the usability. I suppose.

F

Well to to be fair: what in in what I said, the extension method could just do the conversion itself and then call the raw's bite overload. So I'm.

L

I will leave that obviously up to the artboard uh api board. um I think from my from what I understood. The scenario should be: the only need the ross byte ones, but I can see some people wanting the other two and you can add them to you guys.

F

I I guess from a usability perspective, if you really don't care about performance, if you just want to control, what's going out on the wire, because you're doing your own custom converter, then it might just be more convenient to use strings and take the perfect um yeah. I think. For the most part, most people don't care, and the raw's by overload is there for people who do care.

F

Which you would absolutely care in your scenarios right.

L

F

As in like, if, if you ever had to call this from within the sdk like, you would call the rosvite overlay correct.

L

A

All right so so.

L

Either then it looks like the.

A

The char and the string, one.

L

No to keep keep to keep it okay, so I think the only suggestion is to rename the parameter to be something like skip input, validation, and maybe we just emphasize that in a dot comment that it is very specific of wow. This is different than the global option.

L

And also, I think, a lot of this. A lot of the heavy lifting over some of the caviars or things that libra mentioned would probably be very, very useful in the comments, as well as notes or remarks that they look about utf-8, encoding and some other things, especially because this is we especially name it as write raw just so that people know what they're getting.

L

L

Yeah and again for completion, I'd, say sorry, one uh I'll shower say so leo me, you had an alternate design which was around using a flag's enum. What do people think about that as a in the future? If you ever need that uh control, we could add them in the future as an old lord. That seems reasonable, correct.

L

C

It shouldn't slash since there's no there's no global configuration on the writer, so.

E

C

Be able to have.

E

A default value but yep.

L

Which would be the same as this one.

A

R

We could just.

A

You know just add an overload with more booleans right if it's just a very small set. It also seems fine.

F

I think um naomi, when you and I spoke the other day, uh didn't you have an idea for, like some uh options struck that you could pass in potentially.

C

Yeah I did, um but an enum seemed better because it could express the same set of options and we do have issues with um like value copy semantics, with a struct within his trucks. So it was nice natural so that that struck turned into the flags. You know.

L

Okay, so to your point, you know earlier when you mentioned that we might want one overload that in the future that takes both property name and value. I would imagine that would be called write, raw correct uh to follow the pattern of light raw and then write, draw right, x and right x value. Do you think it makes sense to name this write raw json value and similarly the other one in the future? If you were to add it would be called write, raw json or no.

A

I mean that was my kind of the other thing I wanted to talk about is like is raw the best phrase, because raw to me kind of implies what christoph said earlier about like kind of partial text versus, if you say right, jason, you kind of imply that it's a self-contained json value right.

C

When you skip validation, you might not write.

A

Jason right but the intent is you do right, you just say: don't don't check me on it, you're still promising you're doing you're doing.

L

I think the only one of the reasons why raw exists is because no suggestion called it raw as well, so maybe there's a familiarity aspect or a real aspect, but yeah yeah. I buy your argument.

G

Oh, so what is wrong.

I

Whatever you want, when you say jason, it sounds like it needs to be well formed, in my opinion, even with the skip validation.

M

But it does need to be well formed. I.

A

Think that's the thing like you're just saying. Don't check me on it right but like if you don't write well form json, then you don't have correct code, because now we assume it is a complete json object. So me after you call that we may actually insert commas and stuff right. So, like you, you will definitely break your stuff. If you don't write a self-contained json radio.

I

Well, you can, you, can write, um json, that's not structured properly and that can't be deserialized.

B

uh For what it's worth, the terminology used for uh equivalent methods in asn, 1 and the sea war writers is right and coded value.

A

Yeah, it seems technically.

A

A

L

This is on the fence here, say: either: write raw value or write, json value or maybe even write raw json value. All three of them are seen fine to me.

A

I think the problem with like, I think, to me the reason why right raw value works is because value implies something right like to me write raw value and kind of implies. It cannot be just arbitrary text, but as soon as you do the overload where you say you accept the property name, you would call it right raw, in which case it seems a bit weird. So I actually like.

M

A

Of something json in it.

M

Yeah, you know the reason I kind of missed initially that value means json value was that kind of in pcl apis. We have lots of.

M

You know things that are called value and it just means like an you know: either either an object or a value of a value type, and here it doesn't mean any value. It just means specific json value, but I kind of agree that we may be splitting her and any of the three options are good enough.

C

Yeah, I personally don't like jason in the name since it's a jason writer, so it kind of feels you don't don't like drop jason, jason.

A

Yeah I can buy that.

I

Does something azure um kristoff call it data like json data, their type.

C

Right through a data, something like that.

I

Azure sdk has a type called json data. I believe that's similar to this.

E

Yeah, I mean the the reason that value got put in a proposal previously is to indicate that the only correct usage of the api is a thing that is a single legal json value using the term value from the json spec.

M

I agree because j write data or json data well open bracket is json data, yet you shouldn't be passing open bracket only a char or byte. To this.

L

Api, the only the only concern I have with leaving the api as is, is if we were to add that property name or in the future. What would we call it if you think we will never add that, because I don't know we need to because we already have the right property name, then we don't have to solve that problem, and the name is good, as is you mean if we let people write literally arbitrary bytes?

L

No, no. What I mean is if, in the future we decide to add to have parity with some of the other overloads. We have a write raw api that takes a property name and a value.

L

Then the name write raw would be really weird, but that would be consistent with all the other api names we have and that's probably where we want to change it. But if you don't think we'll ever add that which I don't think we will, then this is fine. So.

C

If your the right prop like one that also writes the property name like, would you expect validation on the property name or it should take the same? It should use the.

J

C

Validation option as we're applying here.

L

It would be the same behavior all the other overloads they take. Property name, which is the property name, has to be valid.

I

Yeah as you're usually saying that we, for example, we have right string today and we have right string value right string implies. We also pass the property name.

I

So we use that pattern all over the place and if we try to apply that pattern here, we would have a api called write, just write raw that would take the property name, but that sounds a little weird right. That's what you're saying.

L

Exactly that's exactly.

L

But as long as we don't have that overload- and I don't think we need to because we- the scenario can be solved by just having the two methods like property name and then write raw value, then we don't have to solve that problem. Therefore, the name is good.

M

Yeah, I can imagine, I don't think it frankly matters, but one method that takes both property name and the value would be probably faster because to write it. You need to extract spans for the buffer and then it's you know faster to extract the span once as opposed to two separate calls.

C

Did you do something similar to what christoph just described in the right string like? Are they optimizations beyond just not calling the method twice.

C

If you, if you recall, awesome.

L

uh Sorry, if the performance would be impactful is that what you're, basically getting at yeah.

C

Like are there optimizations beyond just not two method, calls in the right great x methods.

L

I think I think it would be really hard to make that justification. I think the difference was more important for things like uh right, raw right number, because they're smaller payloads and then we I measured it was, I think, five to ten percent improvement. But in this case, because we're writing a whole bunch of string and it's very much- uh we just complete the whole uh binary data. uh I don't know if that'll be that impactful for us to care, but why? But what do you say? Maybe.

M

The value is just you know, one byte represented representing a digit.

L

Right right, yes,.

C

In that case, it might matter. Yes, I'm thinking about similar things for like fast parts to use instruction.

C

I kinda deferred that for now to measure stuff correctly.

L

In that case I mean in the future. You could the other option you could have if you were to add that overload, is break the pattern and say write wall brought, write raw value with property or something like that or make a different name unless, like I said, the three options we have on the from the naming perspective, I think all three are good uh pick. Whichever um yeah I mean so.

A

Sorry, I gotta run that.

L

Yeah, I don't know.

A

I think in the in the end, it's an advanced apis, even if the name is not 100 there. It's probably fine.

B

uh Hey mo, I have a question about the second bullet that you put there uh you're saying that, even if we said skip input, validation to true, we should still be checking that comments are present and we should be stripping them. Is that really something we should be doing?

B

It kind of feels that we have a hierarchy in terms of what is really important and we should be ignoring sorry.

A

Like I messed up, then I wanted to say: if it's false, we should enforce. The comments are not present. Okay, I inverted the logic.

C

I think we'll just be forcing that they're, not they're, not trying to re-parse or rewrite the data.

I

Yeah, I think, with the term raw in it. If we.

B

Yeah, I think, as long as soon as people want to have changes affected to the input, then the existing workaround should be like the proposed alternative using json document.

E

Yeah, because, if you put, if you feed json document to json reader, that allows comments, json document won't know how to store them and when it calls right. Actually I don't remember if we called direct copy on the bytes or if we uh did token by token, walk.

E

So I pointlessly rambled.

A

So the do you like: does the dom contain white space and comments? No right.

E

I don't remember what we did for right, too,.

A

But I think you have the underlying text right, so you could probably just copy that.

E

Apparently source.that is not indexing again.

A

C

A

I mean honestly like if you need to have users inputs truthfully represented, I don't think any of our doms in the framework. Do that, like neither does xml like xml kind of preserves white space a little bit, but, for example, if you break up your attributes or multiple lines, it can't represent that. So it's also script and comments are just represented in xml, because conveniently they are syntactically constrained to where elements need to be so you can actually represent them versus in only you know, in json you can put them anywhere.

A

You want right before the colon after the colon, and so it's kind of like c, in which case, unless you do the roster model, where you have you know full trivia support where anything can be stored anywhere. I think you kind of have to accept that there is loss and fidelity.

E

The the json document model writes token by token, so it it pretty prints your document and it would strip comments if you gave it a comment supporting reader.

A

Right so basically, it's lossy right in terms of the way the user formatted. It is not what you would give me back.

E

Right, but, depending on what your scenario is that like, if you want a fully pretty printed document, you can basically do json or open it as a json document feed that to a new reader, and that's that is, and that is a way to get a pretty printed commented script document right.

E

It just happens to be that exact logic.

A

So, basically, the the limitations. Still we could not 3d print a document and give you comments.

E

Right, someone would have to write their own reader and writer loop to do that right.

M

So maybe I missed something: are we gonna use for the implementation that does not skip validation? Are we going to use json document? Are we going to use json reader.

C

So the implementation that that validates will you use the the document? No, we just look through the reader and make sure like it doesn't throw maybe catch it without exception and then through something more sensible.

C

Yeah, we don't do this workaround because we don't like, like the performance, isn't the best.

M

Okay, yeah. I just wanted to make sure, because we were talking like today for user code. We recommend json document as a workaround and I just wanted to make sure that we don't use json document internally to implement the validation, yep.

D

E

All right seems good to me.

A

Cool so then, I think let me just check that I didn't add more notes. On the other side, I think I might have um all.

A

A

All right so then, I think uh we have still 18 minutes left. So I'm not sure how far this goes, but it seems we can just give it a shot.

A

Jeff is that yours, or is that somebody else.

P

This is ours: yes, um I'm gonna ping anton because he's the dev on this, but um give me one second.

D

B

I think he said in the comments that he had to drop.

E

Yeah, I think so, and that he's letting jeff represent it. Okay, yeah.

P

Oh, I think he said he was back well, we'll see if he shows up anyway. um We are um improving the way that we do hp to flow control in this release um and we're still not sure exactly what we're going to implement here.

P

But but what we do know is that we do what we do in five: it's not very good and so there's two options here: either we do something dynamic where we basically try and detect how large the window should be, based on trying to estimate, rtt and bandwidth and stuff like that, which is very smart, but also kind of hard to do and maybe overkill um or we just basically let the user set the uh window size themselves.

P

um So the the uh the proposed api here kind of covers both cases. um In other words, the the default plan basically is to have this dynamic model where, in order to uh uh make the dynamic model work, we want to expose these two properties. One is just enabling it enable which we've called enable dynamic, hv2 stream window sizing.

P

The default will be true, but just in case uh it doesn't work well for some scenarios we want to enable the user to be able to turn that off.

P

The second property is then just the initial size. So that's what it starts at before the algorithm kicks in and starts dynamically sizing it. The algorithm by the way, will only ever size it up. It will never size it down. So that's also a minimum and um again we want that to be configurable so that if you in fact know that you need a it's basically, these are basically perf tuning knobs.

P

um If we end up not doing the uh dynamic sizing, then we'll simply remove the dynamic property and leave the initial window size property, except that that will be initial and permanent window size, property.

P

So that is the uh proposal.

A

I mean it makes sense to me I mean the naming seems to be some other limit. What you had before um I mean I assume http 2 implies that it only applies to http 2. That http 1 has no notion of that right.

P

Does not apply to hp1 for sure there's something of a similar notion in http 3, but we don't believe that that that you'd want to set it in the same way. In other words, we may need something here for hp3 in the future, um but uh we hope not.

O

Jeff for the dynamic.

O

P

O

Expose the ability to turn off whatever their heuristic is.

P

O

It just seems a little bit like we we're leaving ourselves an escape patch, because we're not sure if we have the right answer, but we don't expect anyone to actually ever set it to.

P

P

We hope that nobody sets it to false, but it is an escape hatch. I will say that, like the like windsock lets, you do this. So winsock does something similar to what we're proposing here, which is that it will. It has an algorithm for estimating the um receipt window size uh and you can go into winsock and say turn that off or set it to a particular value.

P

No we're not winsock, so we don't necessarily need to expose the same knobs that they do, but.

P

It it is kind of an escape hatch.

E

Yeah so two questions on that regard. um One would it just then, make more sense as an app context switch. If you don't really expect anyone would do it and two would disable be a better name for the thing to indicate this property is what you like. It's sort of the you see the property, and you have the question of.

E

Should I set this or not and within able it sort of feels like oh it's off, and you kind of want to tell it to turn on, but you're trying to assert that like it's on, unless you want to turn it off um granted, it's a property and you can look at the default value. It's just. You know as indicating to someone without reading the docs to find out what the default is. Yeah. That makes sense. I think.

P

That's probably, I think, that's better anton. You agree.

R

I agree with the disabled uh for uh context, which I think, uh like the big difference is that you cannot set it on a per handler basis, and I can imagine that an application, for example. If if ever, we need to use it or if ever any user has to use it, it can be just in particular cases like some.

R

I don't know grpc, for example, uh may disable uh the dynamic window and just set some high uh stream in those size. So I think there is some value to be able to set it up by handler basis.

O

Just to clarify my previous question is it is it that we know there are certain niche cases where you would want to disable it or we it's an unknown unknown and we're just. We don't have enough experience yet to be confident with our heuristic and so theoretically. Maybe someone would want to turn it off.

R

Well, I I did some research on how servers behave with being flat production, but like it's not like a hundred percent, we just don't know like if there is any server in the world that uh kind of violates any back best practice or not necessarily sir, it can be uh middleware components, such load, balancers or whatever that that may get into the way for for a user yeah.

P

To explain what anton's talking about um the other reason here is: it's: it's not just an escape hatch in terms of performance. It's also an escape hatch in terms of uh uh an issue surrounding how we measure the rtt. So the plan is to measure rtt using htv2 pings.

P

um However, their servers typically implement some form of ping flood protection, in other words, uh a a denial of service attack via hp2 on an hp. 2 server is to just flood it with hp, 2, pings and so servers typically have some sort of on by default heuristic to say. I think, you've sent me too many pings in too short a period of time, and I'm going to tell you to off.

P

We, the research, we've done. We believe that the way that we will use ping to measure this should not trigger those, but you can't be 100 certain and if it did trigger it, you'd be dead and you wouldn't be able to use hp2 at all.

O

A

So my other question that I was thinking of is like, I think what was uh I think, jeremy suggested to call it disable if the default is enabled. You already have enable multiple http 2 connections. I assume the default, for that is true.

A

No, the default, for that is false. I see well. In that case it would probably make sense. It just seems odd that you have one enable and one disabled, but uh yeah I mean they have opposing defaults. True.

E

Yeah so I mean you know for the.

E

I can appreciate that the app context is a is a global switch of turn off the support, um but sort of my feeling and feel free to disagree is if we don't know of cases where people need to turn it off, then we don't need the api yet and they can turn it off globally and then you know be upset that it's off and then file the issue that they wish. They had it on a per handle basis.

E

And then we add the api, but it's sort of a maybe we don't want to add an option that we have to support forever. If we kind of don't think anyone needs it.

R

That might make sense, on the other hand, if for any reason we will feel like it has to be an api edition, we cannot add it after release or cannot like. We don't backboard api changes so right.

E

It's just a feature in the next release.

R

Yeah yeah see on the.

E

R

It's kind of not like it's a must have if you implement like. If, if there will be a problem with an important use case, then it's a must have to have a workaround, uh probably a contest which is good enough.

R

uh We really like just don't, don't have the time to do the extensive research like what is what is the perfect thing to do this to do here? So it's it's indeed an escape patch can accept an argument that it it would be better to have it as snap contest.

E

Switch yes, api is forever and app context which you can decide. No one asked about this for two releases. We're gonna, delete it and there's no way to turn this off anymore um and that's really the where I'm coming from on that.

E

Don't don't stick yourself with the thing that you'll regret in a couple years, if you can avoid it.

A

So then conclusion is: we don't give you the enable for now and we leave it as an app context, switch.

P

I'm fine with that. It really is an escape hatch and so absent evidence that that that we need the escape hatch. I think that that having it has an app context, which seems reasonable.

A

All right, then,.

P

So that brings up the issue of the other property which.

R

I believe it makes sense in any.

A

Case this one seems like a perf tuning thing right where there is not necessarily one correct answer so having that on a per handler basis seems pretty sensible right.

R

Yeah there might be a use case if, like someone really has to disable it, they will also have to change this property, which is kind of looks very dirty in case like the escape each patch has has to be used.

R

But on the other hand, it makes sense on its own, probably.

P

We could also change the default if the app context switch disables the dynamic. We could have different defaults based on whether the dynamic sizing is enabled or.

P

Not that's a little funky, but it might result in a more smooth user behavior in a smoother. You know, experience.

R

Yeah the other hand, like I, I had a brief look on how other frameworks implement it, and then they just basically exposed these options like gore or node or whatever. So, but maybe we have a different uh kind of strategy here and what what properties they expose, for example, stream, window size or yeah. Of course they they don't do like dynamic things. So probably it's that's the reason for that.

E

E

A

All right anything else to end or is that it.

P

That's it. I think you happy anton.

R

Yeah you're fine, with this great.

A

All right, so um we only have four minutes left, but given our track record, I don't think we'd be able to do anything useful in that.

A

So I would just say I see you guys probably next week because I don't think we have another meeting set up for this week.

E

We're not meeting tomorrow, oh.

A

Sorry, we meet tomorrow, never mind they do meet tomorrow, and I think tomorrow we're talking about.

A

Not what we have here, I I think I need to update the invite I think I may have missed the week. I think tomorrow the goal was to look at um the rest. Sorry, the rate limiting apis, okay.

A

And then we have two blocking issues left. We have the read-only span on system hash code and we have the debug assert overloads, which I assume are both easy.

O

A

The first one is.

O

Is trivial we could probably do it in the next three minutes. The.

A

O

One's a longer conversation.

A

Okay, then, let's at least try the hashcode one.

F

Oh, I'm surprised it was mark blocking okay, sure.

O

I I marked it that way, just because there have been two pr's in the meantime that have come up that could have used it, and I keep having to say edit to do comment and it's getting like. Yes, that is a very good reason.

A

All right, stephen, what what is it for.

O

The hash code, struct, has add methods for add of t basically which lets you add in a value, and there are multiple situations where you just want to add in you've, got a reader only span and you want to add in a bunch of values, um and so this is add of read only span byte to add in a whole bunch of values.

O

um Usually it's you've got something that already has either a byte representation or something that it's you know like a read-only span of uint or read-only span of enter byte or whatever you can. You can also cast it down to a read-only span of bite and pass it in.

F

So that's it by the way, the api that we very recently approved, non-cryptographic hash algorithm, uh has ad of reasonably span of byte as an instance method already. So this would give us parity with that.

E

Well, that's a pinned but sure, and what's this um do like? Is it for each byte call add-on byte? Is it mixing in the length and.

O

Think I think it should not be constrained to do that, because that would limit our ability to optimize it. um I think it should basically guarantee that if you give it the same uh sequence of bytes, it'll always mix in the same data, um you know within that process, uh but um you know it. It doesn't guarantee that it's the same as calling ad for each byte.

A

Fair enough and how's like, why would we not just make it out of t, but if it only span of t, because that would require to do that, would you just suggest it.

F

There's there is an open question as well. There is a difficult question rather as to how do you hash an arbitrary t? What we do right now is um we we call t dot, get hash code and then for each of those we call add in a loop. uh If, if you were to attempt to give us an arbitrary read-only span of tea, but often that's not an appropriate behavior, um often like one of the scenarios that came up here was like I have. I have a float that I want to hash.

F

Well, I can't add, float to, I can't call add of float um because that's going to reduce the entire float down to a 32-bit uh hash code before it gets mixed in.

F

I guess this would be a better argument for double since double 64-bits, but if the entire point of this is to try to give you like a hash code with good distribution, um really what you want to do is somehow turn the data that you're going to hash into an arbitrary link bit array, and then we can take that bit array and then run it through our sponge algorithm.

F

I'm making all kind all kinds of gesticulation that you can't see it's great.

E

And this implementation is probably going to end up doing something complicated with bytes of like adding some zero padding, because its implementation assumes it always deals with 32-bit values.

P

Because I looked at.

F

E

Like last week,.

F

Yeah something something like that remember: we can always change the implementation under the covers to do whatever we need to do.

E

That's fair, I mean so really. I guess my question to steve: what's the implementation going to do is is do we do we feel that we have a need to document its behavior so that somebody could write equivalent code when this api is not available, but I think we say or but we do intentionally do random seeding. So you can't depend on getting this the same answer across processes so or even runs of the same process. So um it probably.

O

Doesn't I think we shouldn't document it any more than we do for arbitrary types? You know it's you give us the same data. We're gonna, give you the we're going to mix in the same state into the hash code and nothing more, nothing less.

E

That's fair yeah. I was just thinking of compatibility with existing code, but I think the whole point of this type is it's compatible within one execution, but not necessarily across executions. So yeah.

F

So I would what I would do is I would go further and say if you pass, if you call add with the byte array abcd that could give you a different result than calling add with a single element, byte array a and a three element, byte array bcd, because they are not equivalent calls.

F

E

I feel like you want to hit enter on your chat, emo.

A

Yeah I was about to look whether I already have it somewhere, but I don't have it anywhere. I know for some reason the thing disappeared again. um Oh because I minimized. Let me know all right so then I think that seems fine. Then I mean my only question was: if we end up adding the generic one, then it seems unfortunate to have a specialization, but it's probably also not the worst in the world.

F

Yeah, well, we we couldn't really add a generic one in the end after this, because now read-only span of t would well like us right would just be.

A

It would be weird it would be.

F

Very weird but yeah.

A

I mean if you call it through a generic one. Yes, if you, but we could tribulate, have the generic one just do a check and then dispatch to the other one right.

F

Maybe I again like, if you're, if you're calling this over an array of non-bit data like chances, are you needed to perform some other fix-up of that before calling this api? So I don't really know what it would mean to pass like a span of double in here for.

F

E

Yeah, so I think it's good. I think.

E

We know that there would be potential problems with adding other, let's call them innumerable-ish things in the future, um but that we're uh we can figure them out as as we need to. But that sounds like steve has a plan for this and need for it. So I think it's good.

A

E

Fix the int back to void, oh you didn't fix the anti-void. uh Steve must have done it edit. You had it open. uh The the method is void. Returning steve had a comment of that just being a typo.

E

Looks good to me.

A

All right, then this is it for today and then I'll see you guys tomorrow. I don't have a gavel, so you just have to take my word for it here we go.

E

I've been standing by for like 10 minutes now.

A

All right, then goodbye everyone.

A