.Net Foundation Design Reviews, 2 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: JSON DOM API Review

Description

Powered by Restream https://restream.io/

A

A

A

A

uh Of course, now the team's window is minimized again to make my life fun all right, so we know we are live again and today we are focusing on our jason, dom apis, um steve or leone. Do you want to take it away.

B

Yep sure um so just some background, we did the first apr review um a month ago or so um and based upon that feedback plus other feedback, including um the azure sdk team and additional prototyping um there's, some changes made. The the two biggest api changes since last time was that there was a separate inheritance hierarchy for dynamic, plus and non-dynamic scenarios.

B

Now those are the same, and that was based upon um some prototyping that we had with il linker. That seemed to do the right thing when you're not using dynamic it removed the reference to system link, expressions which is pretty cool.

B

um The other api change um was based upon p feedback around not having all static parse methods and um like two json string type serialize methods, because those are kind of optional. The json serializer methods could be used, um but anyway, based upon that feedback, I added those, and then I added some additional background and stuff to the design dock and we don't really have time to go through the through the design dock. So I think um I'll be kind of quick here and just wait till questions pop up.

B

um This overview section here just says: we have uh a lot of different people that want to use this, including people that want to use the serializer, maybe but can't um so. I I do think that this api will be commonly used.

B

The high level api is shown here, um it's an abstract, json, node based class and then three derived classes for um object, array and value, and then the value has a little twist in it that there's a generic pattern there to avoid boxing more or less.

B

Okay, we can keep going here.

B

So today, um system types ethan does not have a writable dom. It does have json document adjacent elements which are read-only version of the dom, and um this can't really be easily directly extended for writability. So the thinking was that we'll have some interop with that and then create. You know a new api json node for the writable dom, and it could also be used, of course, in read-only mode. But if you want you know, raw performance, json element will still be better. In many scenario, all scenarios.

B

Okay, yeah scroll down, I'm just going to kind of skip this section.

B

um Layering, um this section just says that json node uses json element during deserialization, meaning that um when you call like a parse method on json node, it only uses json element and then it maintains- or it holds a reference to adjacent element um for performance. The super fast lazy creation of nodes and during serialization, then um jason node will will either use json element. If things haven't changed, you know if you haven't modified the data or it'll use the raw values that were added.

B

um You know to the collection or object or set, and then it uses a serializer for that, and I just have a little clarification here, because this was this. This did come up quite a bit last time that you know, does it make sense to use a serializer? So I added this section- and it says layer on the serializer is necessary to support the dynamic cases where you can assign you know any arbitrary clr type.

B

You know whether it's a poke or a collection or whatever to an object, and you expect that to work well that uses a serializer today. um So you know the sterilizer has to be used at some level and then also if we um layer up on the serializer and we have the json serializer options available, then we can support custom data types and other serializer features. If we want.

B

Does that make sense.

A

B

So yeah api walkthrough section um to kind of reiterate some of this. It basically says when you deserialize json node. Again it's going to hold on to json element um and it and then, when you kind of switch to an edit mode, where you start then modifying values or adding values to an array or mod or an object, then you can enter this edit mode and then you no longer really use json element.

B

You, you know you create the raw clr types um for values like you know that um a double for example, or you create a json array to represent a a collection or you create a json object to represent an object with properties.

B

So once you once you enter this edit mode, um json element is no longer used and instead the rob um clr primitives are basically stored, and uh I have a code example here which is important because if you just want, if you have a adjacent node- and you know it's a primitive and you want to get the value out of it, you don't really care if it came from a json element or if it's in this edit mode.

B

So the api is the same, no matter what which is important, because you don't want to have you know an if statement whenever you want to get an integer out of a json node. So that's what that code example. There is showing.

B

Okay, keep scrolling.

C

So I have a question about your modes here steve.

C

So if I were to load a document and have this tree and then take presumably once I modify something, you have to share upwards that basically the dirty bit is now set. But if.

B

C

Node and add it again inside the tree, basically intending to make a copy like is.

B

C

To work, or is that going to create all sorts of problems.

B

Yeah yeah and the prototype actually does do this already, so you can use that as a reference, if you want, but what it what it does is as soon as you touch it adjacent object, for example, you add, you add something to it. For example, then it will convert those json um that internal json element to json nodes.

B

So if you have an object with, you know, 10 properties internally, before you touched it, it just hold on to adjacent element, which you know points to a json document which contains your raw data somewhere um but yeah as soon as you touch it the same for an array, then it will um kind of throw away its internal instance and and populate.

B

And- and there is uh yeah the dirty bit does does propagate up um it's needed. I guess for internal implementation. I mean.

D

B

Itself um that the json array or the json object knows what moduson it doesn't necessarily expose. It.

C

And does it? Are you converting the whole tree at the first dirty bit or only the relevant parts.

B

Yeah just that one node- and I do this- is discussed a little bit later on um it's so shallow um creation.

C

Okay, just trying to keep semantics in my head.

B

Yeah, it is it that is important, it's not obvious. um What's going on because jason, node and jason, I mean sorry on json object and json array do not expose any kind of property that lets. You know what mode is in it just will switch um based upon enabling edit mode.

E

Steve, I have a question about like something that you said you wanted originally to just modify, modify json document, and then it turned out to be difficult. So we created this, uh you know somewhat separate api.

E

One thing that is kind of different between the existing dom apis and this api is that that existing dom api there's only one class and it holds byte array and you can refer to you- know json. You can kind of work the virtual tree of json elements, but json elements are struct, so they don't cause basically walking the tree doesn't cause any allocation in this mutable dome design.

E

I noticed that all the elements are classes and therefore walking the tree will will cause allocations. Would it be possible to implement it such that?

E

You know the root is a class, so it holds the json element or the database, but then working the tree does not cause allocations, which means json object, drifts on array and json value would be struck.

E

Then, of course you couldn't have a polymorphic hierarchy between these things as you have today, but I wonder whether the polymorphic hierarchy is important.

E

B

um Yeah there's a lot to that comment. um Yeah so I mean originally. When we created the read-only dom. I think the intent was that maybe we can switch. You know enable editable in some cases in there, but it turned out that um did the prototype effort in fibo that that was kind of abandoned, and I I others can chime in here that were part of that.

B

I wasn't directly involved with a lot of those reviews, but in either case yeah, so it ended up with a model similar to what we have here with classes and not structs, um primarily because yeah it doesn't allow an inheritance hierarchy.

B

um Also, it's kind of natural um for like link and stuff like that, where you don't have to rehydrate objects all the time and you just hold on to them that you know has some um performance cases in certain areas.

B

But if we wanted to.

B

And I'll back up a little bit and say what I said earlier: that if you're in read-only mode, you can still enumerate um the entire graph with very minimal minimal allocations, for example, if you're just reading um at a certain level, you need to go down 10 levels, you can go to found 10 levels in your graph or um and get a class out of it, and you won't have to necessarily affect other things within that graph. So if you're just doing a partial, um you know graph or tree walk, it is fairly efficient.

B

I think it's as efficient as you could get with the current design. Anyway, if you wanted to avoid lx and and as you um like, you said and then uh somehow store those like, we do with jason document yeah, that's possible. I guess um I don't know how important that is right here.

C

I I mean the biggest problem: kristoff was the api usability like the the fact that it's rep, the json element is representing several different types. Methods are all mode based, it's a very complicated thing to use, and once we started adding editing into it, it got terrible, and I think that the same would be true if we tried to make a second thing, having the same struct semantics with complexity like.

E

Well, I'm not sure how you're avoiding it here, because json node is basically a union of json value array and an object so and all the indexers and all the accessors of properties return json node well because they have to they can be either arrays objects or values.

E

And then so you kind of have exactly the same problem.

C

Well, except jason, node doesn't have all the all the members on it. You have to now ask what the thing is and use it. Instead of I see all that these things are available and now 90 of them throw at any given time.

E

You're saying you have to basically cast json value to appropriate type to be able to, like you know, treat it as an array or an object. Is that correct what you were saying.

C

I mean that without looking at the api surface, that's my assumption, um but yes.

E

And it's the type guided member.

C

I would say.

E

I think you can do the same thing with sharks. Basically, you have a you know: json nodes, struct, and then you have to check whether it's an array on there or an object or a value, and then you cast it and now it's not a natural cast, but rather a cast that is provided on json node and it lets you cast it to you, know json array or json object or or a primitive value.

E

I think the same thing can be done with struct. I wonder what the you know them there probably is some trade-off. I was just kind of observing that we created kind of um now. The user has to choose, do they want something that is very mean and allocating or they want to mutate, and it.

B

Would be choices like.

E

If this whole graph was a bunch of structs, it would have very similar performance characteristics, at least when you read it or actually it would have exactly same performance characteristics when you read it as if you just read json element.

B

But there there will be little nodes involved as you navigate downward, but yeah.

E

Yeah but the nodes would be basically a small structure that just stores you know the string that the user passed when they navigated the path. Okay,.

B

E

B

The it's not not assuming the struck today is very if you're just reading, it's very optimized for the read cases today I mean the current design. It will create one instance per node as you're navigating down one. You know, instance of a class, um but it won't necessarily fully populate every child or array element, etc. Until you touch it.

E

Yeah but then it creates. Basically it does an allocation per path per node in a path and with structs you could avoid it. You would have basically exactly same performance characteristics as json elements, walking, json elements.

C

Right but then now you're you're using a so it sounds like you want to have a struct. That's basically, a a cursor mask over correct.

E

C

Over the reference data anytime, you mutate it you'll have to have reference data, otherwise or because you want class-like semantics, but now we are introducing this. It sounds like a massive complexity of well. You know that structs have complicated mutation semantics, but this struct is okay. It totally has same mutation semantics because it's not really a struct, it's a cursor and we don't really have those and like it feels like you're suggesting introducing a new concept.

C

I don't think it's a.

E

New concept, but you can mutate the s-pan and its structs, because you mutate the value of this fan that itself. So it's the same, correct.

C

uh I guess I could buy that.

B

Okay, so I kristoff is coming from the azure sdk side, where they do have a single, concrete, json data type um and we have yet to and one of the to do's we we have on this is to work on some usability studies. They've already done a lot and um also you might have some performance characters characteristics that we haven't.

B

You know um moved up, but I I do think that it would be interesting to compare json data in edit mode, for you know, for both cpu performance and for memory and and measure the results, because I I don't think um depending on the scenario I I I don't know how important it is. I mean it's, you can create yeah, definitely thousands of of instances of json nodes in an edit mode. If you're, you know setting thousands of properties, for example, or adding thousands of elements.

B

So if that is um uh important use case, there's a couple things we could do. We could switch to something like that with a single struct or we could actually add if we wanted. If the. If the modifications are somewhat sparse, I think we could have better interop with json element.

B

There are some interrupt with json element already that enables you to forward to a node, but we could also have interrupt where you can ask for a node from a json element and then modify it and then I'll write back to the to the json element. You need no json element, you know temporary json, node or something and then back again so I mean we could do something like that, but I I think that, for purposes of the api presented here, we should table that.

B

I mean we can't design it here. Yeah.

E

I I and you know like I can see that many of the apis that you already have are kind of independent, whether you know they are struck. We end up shipping tracks or classes. So I totally agree with you that you know like.

F

E

Kind of uh move forward and start talking about the other apis, but I do think that it's an idea worth exploring and to answer your question about whether it's you know worth it or needed the way I think about it is if there's a cost of doing something like this like there are some negatives that we can articulate, then surely there's a trade-off and we should think, like you know, is it worth it and measure performance?

E

You know hid from classes, because if we have classes we get these other benefits here. It seems like at least I don't understand what the other benefits are of classes.

E

So I would kind of just try with tracks it's cheaper and then you know till we know what negatives of trucks are in this in this case, but I thought I think I honestly, I think the only thing that would change if we change these things to sharks is that um you know the the cast would not be natural costs.

E

You would have to add implicit or explicit costs uh to the to the structs and then, of course, the implementation would change a lot.

E

And maybe you know some like lifetime semantics, but I don't think it will affect the api surface, buy a lot.

A

I mean I can buy that, but, like the one thing I think we should avoid is that we build yet another thing in the middle, because, if there's fundamental limitations that we can't easily provide, for example, let's say we want to support, link style navigation operations, and we say: oh that doesn't really work well with structs. Then you know I don't want to have the world eventually have three domes right, a purely the only one. You know a cheap read, write one and then a convenient one right. That would be pretty terrible so like.

A

If we go down that path, we should make sure that the design scales towards the things we may want to add in the future as well. So we don't just keep innovating like keep inventing new dorms right. That would not be a great direction.

E

Yeah, I completely agree, but I don't understand why it would affect link.

A

So that's what I'm saying I mean it's just. It was one example right.

E

A

Like, for example, like I don't know how well these pattern matching thing in c: sharp works with structs, for example right, so it's possible that that's not quite as nice, as you know, the sample code that we have on the screen right now, right, yeah,.

E

Yeah, so if we, if we discover concrete problems, definitely is what I was saying like. It would be good to know what the negatives of making these things tracks really are right, because it seems like now. We have some ideas that there may be some problems, but nobody really knows how to like articulate concrete problems.

A

I mean we do kind of know that structs as soon as you do mutations are getting complicated right. So I mean that's, certainly something we have to figure out how we maintain like identity and reference semantics. As soon as you manipulate the dom right- and I can totally buy that we can have internal classes that do that for us and we just basically do them lazily, and so we can get a wave of allocation free reads, for example, but you know we should really make sure that we can do that in the way we like.

G

And at the same time, if you look at how other languages do the dom, it's generally, you generally get reference semantics, not value semantics when you're manipulating it. If you do dom dot, you know, item dot, nested, item dot, nested item and then mutate. It you're mutating the original dom. Whereas if we're returning structs you're going to get a copy, you have to mutate the copy and then reassign it back.

E

No, no! No! So that's that's not what I was thinking. What I was thinking is: it works like json elements and json document where all the data is in the root and the root is a class. The structs, like jeremy, was saying they are basically just uh cursors.

E

They mutate data in the main database in the main type. They are just cursors.

A

Yeah, you could imagine effectively that all the structs are just holding on to the root and then have some sort of id or whatever. That represents themselves right and everything is expressed.

C

Over there it'll be a very complicated dictionary since the struct can't change. I'm holding json elements to I've now mutated element, number 17., so you'll end up with a basically a dictionary. That is the size of the number of elements in your tree, which is possibly going to end up being worse than if you just had particle semantics.

G

Well, and if we already have a tree, we have nodes between trees and therefore reference types. We can return and we're not allocating in that case, because it already has been allocated.

E

Anyway, we shouldn't be spending too much time on it. um You know something to think about and or explore, but up to you.

A

Yeah, so I think, for the purposes of this meeting, let's let's go with the design as it's proposed right now and then maybe we should have a separate follow-up. That just says like how does the uh like it sounds like you guys, already have a struct-based design that you usability tested and it would be worthwhile just looking into that and see how that fares.

E

Yeah, we don't have a struct by the way. Yes, we we do have a type that is like this. We would prefer to use the bcl type. The main worry that we have is usability. So you know I I met with stevias today, and we talked about kind of at some point during disability study of this api.

E

um We tried several approaches. All of them have very significant problems, so I think this kind of you.

B

E

It's not that we have the right solution.

B

Yeah, so I mean, even even with the proposal that you have um just based on usability alone, you you might be tempted to switch to reference semantics.

E

F

E

Let's move on because we basically we since we don't have a tree, we don't need reference semantics, but we don't have polymorphic hierarchy. We just have one type, so it's a completely different design, but I think we are kind of like now tangential and it's not.

B

Going okay and yeah and backing up a lot more that, um as I mentioned in the beginning, the design was based upon learning from different areas and- and you know a couple of the reference, the the two reference implementations we kind of have are the prototype we did in fiber, which has reference semantics and also newton's soft j token, which has reference semantics, um but yeah.

B

We, let's just hold a follow-up after this then, and um we can both think about it, and I can you know, do some additional prototyping if we need to and on that yeah that's good.

B

Okay, um yeah keep scrolling down, we can get to the api portion. This is uh background. Reading, okay, so it starts with this um abstract, json node class. um That interface implements. I dynamic meta object providers for on the c-sharp dynamics, support it's there's only one method on it and it's implemented explicitly later and um originally uh a month or so ago we had to have a different inheritance hierarchy, because I thought that the linker wouldn't be able to remove on the references system link expressions, but it turns out.

B

I can um I'm not sure um how you want to do. Example, I could walk method by method or um you can watch method by method. You have a preference.

A

So I I I guess like last time, I took some high level notes and maybe it might be you worthwhile to just ask the questions and how the design has changed to the notes from last time. That might be good as a starting point. So last time I said, like your design is seems to be intertwined between the serializer and the dom um giving it the cursory read. It looks like you have kind of undone that uh can you talk a little bit about that.

B

um Well, at least for sure, let me explain these these, um these church syntax support, which is um the the this method indexer for int index. um So this is kind of interesting, so um yeah, the indexer that takes end the command says it's for jason array, church syntax. So this allows you to quickly get an element of an array without having to cast it to json array and then the same for the property name, the string based property name below it, so that was there before.

B

However, we added these get value methods down below which are similar in concept to the json array and json object, quick ways to get um a node out, and then we also added. Then um this git value I take a bounce from between two and get value for terminology, but in general there there's this pattern here, that's not completely obvious and it's there's three different methods, not counting overloads on git value that allow you from the base class json node to quickly navigate.

B

You know down a deep tree to the node you want, and this is based upon feedback from azure sdk team and it's also consistent with newtonsoft um and and the alternative, for example, would be to have json node directly implement. You know I dictionary and I list like the videos array and json object implement. So so it's not quite obvious, um but I want to call that out that it's a pattern that prevents a bunch of casts from occurring- and that is explained a little bit later on as well in the dark.

E

um Quick question: your method get value. That is a job to.

B

Get it could be that I have a typo here. Let me see.

D

Our json value of t.

C

It's about halfway down on the screen right now, public virtual get value of type to get right. Now it's returning nullable json value.

B

Yeah, I'm not that's a typo. Sorry.

C

B

Yeah good touch.

C

B

Sure that's a typo. I don't know why, um for the other ones above it for the json range json object. Of course, you're asking for a specific node in this particular case, you'd have to call git value twice so yeah yep, that is the type.

E

And then I so follow up, because the moment it returns type to get can it be nullable unless we, given that we don't have a constraint on the type on the generic type parameters, I I don't think it can be nullable. If it's not constrained um it, can it even.

C

Gets the maybe null attribute.

C

But if it says right, the maybe null attribute is if this is a struct, it is t and if it is a reference type, it is nullable t.

B

And we do that all over today with the serializer apis, because we allow return either struct or reference type with that. So.

E

If the, if the value doesn't exist um and it's a struct, you return the value, zero extract.

F

I believe so well.

B

So the the nullable semantics are talked about a little later, um but in summary, or at the highest level, we we have to make a decision and on whether to return null or return a singleton that represents null. You know, jason null or something, and this design, including a month ago, whenever we reviewed it last assumes null cl or null semantics.

B

So it will return null if the json is null. If you have a t value, that's not normal of t. You know you're going to get some sort of exception, so.

E

B

Distracts you're going to get an exception, otherwise you're going to get a no. If it's a if it's not a nullable of t. Yes, you I mean you can't assign a null to an int. I mean um there's a concept of default values and stuff, but that hasn't been. I mean you treat knowledge of default values.

B

E

It's just to throw for various types and and not for reference types.

A

Well, I mean it depends on how you're asking but like so if I say get value up in question mark, does it mean I get now.

C

Right, you will yeah and.

A

Assuming that the node.

C

That you're pointing at is the json literal in ull like right there. There is an int question mark of that. There is not an end of that and there.

A

C

A

C

A

C

A throw and the other two are not.

A

So that makes sense what did that mean for reference types? You would just get null and four vagina types. Well, if you, if you do or not, if you use another belvedere type and you get now otherwise you get an exception. I mean that kind of makes sense.

C

Because it's not asking for a property name you're asking the current element interpreted as this other type right.

A

C

Either the null element or you're not.

A

C

You're not representing the json.

A

Yeah I mean I can pass in in question mark and get same answers. I think that's fine.

E

B

With the the serializer right um jason element, json document, our jason element today returns a single 10 for null and then the serializer of course has to return null because you know they're using clr semantics. So for json, known since kind of error on the side of the serializer people expect clr semantics. Not um you know, I guess value semantics.

E

Oh, I I don't. I don't uh I'm not concerned about it returning now. What I'm concerned about is sometimes returning null and sometimes throwing for some for conditions that seem to be the same.

B

Yep, so you'll get an exception when you have n-u-l-l and jason and the type can't be.

E

Known yeah, if we, if we are not concerned about that, I think.

B

um I mean I would expect that I I don't know I mean, for example, I don't think we want to return integer of zero when you see a null in the database. Some people have asked for that for the serializer and I'm not even sure where we landed on that um for default values, but we I I didn't factor any of that into here. um You know we can always in theory, add that later as an option.

E

B

Would be, it would be.

E

Nice, if you know type parameter, question mark meant the uh reference type or nullable of value type. But that's not how the question mark works because.

C

E

Would be consistent, we always return and all value. If we, if you know it, cannot be cast and if it's a reference type, it's a natural null and if it's a value type, then it's a nullable of the value type. But that doesn't work. So I guess we have to have two different behaviors.

A

Slightly different, I mean: can you overload based on constraints? Can you have one api that is constrained to reference type? Another one is because it's constrained to a value type. No okay, then too bad.

B

Well, you, you could but there'll be different names right.

A

Yeah yeah, that's not overloading, though that's that's just separate method.

E

Yeah then I would leave it as it is. It's it's a bit weird, but I guess people would just learn.

B

E

B

When in doubt, if they're not sure, if something is notable, they should just you know, use noble billy types, I mean use a noble teeth: um okay, I'll keep going here. um What else um parent and node properties? I think those were there before- are parent and root um the path property?

B

I don't think was there last time it was added, um it's very important, I think for um debugging. Primarily it is a little tricky in a way because it has to adjust to um changes in the graph. So it's not calculated up front. It needs to be calculated at run time, because um things can change. I mean you can move elements around, etc. An array.

A

I mean: should this be a method really because it seems like it would be weird if it magically changes, and it also seems to be something that is somewhat expensive, potentially right.

B

A

B

I knew not to use this path, but it's completely valid to having a method. It might not show up in the debugger very nicely.

C

B

C

B

Or display to call the method and then.

C

Debugger only yeah.

B

And I'd expect.

C

B

State that somewhere there that we basically called two string, I think um which will probably have a path in a in.

C

B

Beginning part of the json.

C

Yeah, if it has to do unique work each time and it's not just adding two integers or something that fast, then it should be a method, not a property.

D

B

Okay, so um here's the new wrappers I added um this and the naming I'll. Just let you go through it, but it's basically a combination of some deserialization and some serialization methods that um I believe are all optional, because you can do this we're using the existing json serializer methods. If you find the right one.

E

I have a question about these methods. How do do you think that users will get the difference between get value and deserialize? They literally will like look like. They are doing the same thing.

E

I wonder if they could be the same method.

B

Yeah, I do that's a good question. I do call out um some of the rules. I guess for forget value and- and um you know what it does, because, for example, if you call a good value in the in the t that you passed in matches the t on these adjacent values of t, then it returns a draw value. If you have adjacent elements, is there another optimization if you're based on json element and then finally it uses a serializer.

B

So um I think the d serialize just boom go right to the serializer and doesn't have the optimizations, but they could be combined. I could try to flush that out with someone.

E

So one thing it was about combining and second thing is: um I wonder if that the serialized method or any method that may be serializing shouldn't, take uh the serialization options, because I can totally see how people would.

E

You know they use the dom to get json element, instantiate json value out of it and then try to deserialize, but they need to like do renames or some other things that the serializer options led you to control.

E

And you can, I see you, you can do it when you parse, but when you instantiate this thing from json element, then you cannot correct.

B

um Yeah, I do talk about the options later and I and it does say that the options are only available when you either when you call these parse methods or when you knew up a new node um in theory. You could also add them to these serialize. But if you, if we needed to otherwise you, I guess you can always use it using serializer methods.

A

So you're saying basically when I parse the the ambient document that I basically get back has a notion of field other options. But if I just instinctually this guy out of thin air or got it from a json element, then there's no ambient options. Is that fair.

B

uh Unless, unless you pass them in the constructors do take them, I see so.

A

B

It's it could be redundant to put it on uh on the serialize, because you know you had to create an object in order to serialize it.

E

What you could do is basically instantiate. This thing out of the blue then use the mutating apis to create a you know, basically json document, and then you try to decentralize it to something where the property names don't match, and then you basically don't have api today to do it.

B

Right um yeah, I I do have that section down below that talks about this. I recently added it based upon feedback, but there are some um rules that have to be defined around the options, because it's not obvious at all. For example, you could you could new up one object with one set of options and then add another object to that. That has the different options.

B

You know what does it use and then also in your case, um if you wanted to um serialize with a different set of options, you could fall back to the json serializer, dot serialize and pass in the options instance and since you're passing an explicit option. Instance, it would override any options that the node had internally.

B

That was that's the proposal anyway, so you could do it. It's just not available on these apis right here.

A

Yeah, maybe it's just me but like I feel like I would separate these out. I would basically say logically, when you call pars, we use the options to parse, but then the resulting dom has no notion of options anymore. If you want to deserialize, then you have to pass and options that are relevant for that dcis operation.

A

That probably doesn't quite work because you're lazily parsing, probably in which case you need some sort of ambient options to do this basically parsing thing, but I think the the internal options that you get from parsing. I think we should probably not leak, and we should just say those are the options that are used for parts and then, if you want to deserialize the dom at any.

H

A

Point in time you have to give us the options you want to use for that operation and then just separate things.

C

A

Yeah because I think otherwise, I feel like it's hard to reason about you know. How did you get your dom and then you know you get different visualized behavior. That seems harder to reason about than saying. Yep ucla always takes options.

E

Well, so look about. Let me talk about concrete scenario. The concrete scenario is, we receive a payload from azure, it's json and we want to return it to users as json value or json node.

A

E

Common scenario.

A

E

So that the type the generic type argument to either get value or serialize is the user code, we don't know what type they have they can have any type, and therefore we don't know what options to apply when we parse the payload that we get from from azure. Therefore, we literally cannot apply anything. We basically just say: hey here's, some json, that we got. You know parse it with the default parsing and the dom out of it. Well now the user wants to uh deserialize the payload to a strong type.

E

Unfortunately, let's say the property names in the json payload that we receive from azure are different than their type, and you know if it's a very simple transformation, yet they can apply attributes to their pocket type, but maybe they don't own the type or something, and then they would want to use options when they deserialize.

E

In other words, we don't know what options to pass when we call parts.

A

Right, but I think that I guess that's kind of my point is that, like I think so, I don't know exactly what we all store until other options, but there's a bunch of stuff that is relevant for parsing and then there's some sort of actually relevant for serialization right. So you could say yeah in your case.

A

You have what is the generic options because for use just use the data right and then basically you just return the json node uh from your apis and then, if the user wants to deserialize yeah, they have to pass in options right because they they are the ones who own the options they know which converters to apply. They know everything right and that's what I'm saying to me. I would say if, if parsing needs options, that's fine in it of itself.

A

I would just not expose them anywhere, so I would say if you need to deserialize, you always have to pass in options because they're just separate operations like it seems weird to me to say. If you caught parts or you passed in some options in the constructor, then you can defile that with some ambient options, but that now makes it really fragile and also your scenario doesn't work because, as you said, you don't even know which options to instantiate this zone with right.

A

So it seems like the only place where these options are used is if somebody close to zero lights, you should you should just pass them in, like this notion of ambient options seems broken to me. I guess guess what I'm trying to get at. I just feel like for parking, because you do it lazily, you kind of have to probably store them. If you need them for parsing itself,.

E

Correct so I may agree with you except I do one thing I didn't understand. I thought you you. We were about to settle on, there's no way to pass options when you deserialize. I.

D

E

I said always yeah, okay, okay, steve! Is that your understanding and an agreement well.

B

I mean yeah, so there's two two things. I guess one one is what emma said that yeah having the ambient options hanging around after you call parts or you know some deserialized method- probably isn't the best thing in the world. So there is a um json serializer options property on here somewhere. So we would remove that, for example, and it'll just be private and that would be used. For example, let's say you knew up a parent node um an object or something like that.

B

um Json object and then you need to um you have a bunch of properties that you're using implicit or explicit operators on where you you can't pass in the options.

H

B

That ambient options is useful, so you can pass it into parse, but it's not used later when you serialize it. It's only.

G

B

When you um deserialize other other things that you can't pass the options in so yeah, so we could add the options instance then, to the serialize methods. um Here, however, like I mentioned earlier, you still could use the json serializer the existing methods outside of this design and pass the options in, and that would be that.

E

How would you do it? I didn't understand it. So let's say I want to call get value or deserialize, uh and I realized that I cannot pass option. What what do I do? Instead, how do you see the election.

B

I mean first of all we can. We should probably just change the api um to allow you to pass it in directly here, but assuming you we, we didn't, you could call jsonserializer.serialize, which has an optional parameter for the json serializer options and specified that way. No.

E

No but serialize I want to deserialize or are same for these serialization.

B

And what would I.

E

Pass as the payload to this utilize.

B

And in the case, um where you have a string or utf 8, bytes you'd pass that.

E

How would where would I get because, basically, I'm walking the dom and I got to some subtree- I I now hold json node. That represents the subtree and I would want to just call the serialize but there's no options, let's assume on this file, so I have to use serializer. But how do I get the payloads to pass to the deserializer to deserialize because I just hold json node?

E

I could call two string, but that seems like super inefficient right.

B

Right so yeah, so I think you're right that you would have to if, if you had an object and you wanted to um or if you have a node and you want to deserialize that as an object yeah, you would have to get the raw.

B

You know utf-8 fights or the string out of it and then call back from the serializer to get it in.

H

B

Which yeah, which has some complications so do.

E

B

Have a way to get.

E

Robes from a node.

B

Well, you can serialize it as as utf-8 bytes on this method. No there's two json string, there's not a two utf-8 bytes here I mean I have a comment in here that we could add that, but you can always use the json serializer. Okay, that's kind of where this is somewhat confusing. Json serializer has a ton of methods, and not all of them are on here. For example, there's no stream based methods on here and we could duplicate all of those methods. We would also have to then duplicate it.

B

I think um on the json object, json array and json value, so people don't have to do a cast. I.

E

Am really confused, the only thing we need to do is add a parameter to the method, get value or deserialize, and then we are done.

H

B

No, that's yeah, I agree but you're asking. How would we do that without that and that's what I was explaining.

A

Yeah, so I guess my question then becomes is like how is get razor different from these serialized, like are saying, forget valuables, that only works for the primitives that we map, like you, know in floats and strings, but it seems like you can also do get value of my custom struct and then it effectively is the same as the serial.

E

Eyes yeah, we just talked about this and I thought steve said that he will try to combine.

B

A

B

Well, for the d sterilized and for the yeah good value you mean yep yep we could combine. We could combine that deserialize it's it's kind of, like I mentioned that the git value, um as I explained that, like the very first code example, tries to do some optimizations around json element like it knows, hey when you do serialize internally, it's adjacent element, I'm not gonna, take that json element and serializes as a string, and then you know parse it back again or whatever something goofy right. It.

H

B

Gets the raw value out of that json element for the known data types that json element can contain? You know in string that date time that sort of thing anything else that doesn't know about yeah. It has to fall back to this serializer.

A

I mean I mean if we combine them, I would probably settle on get value rather than d0 lines, because it seems weird to call these your lights for strings or ins, but at the same time, if you actually pass strings or ins, it would also be weird having two pause and options, because if you know you're standing on a number like, you only want to get the number. So what options would you possibly need for that?

A

So I think if we combine them, we would probably make the options nullable or you know optional, for like a better term um because for primitives I don't think they make sense, but it will only make sense when you have custom custom, struct or custom types.

E

One note about the name: we few months ago, we designed this type called binary data and we settled on them method. Then the methods to do exactly same thing is called two objects from json of.

A

A

I mean that would be again sensible, I think, for custom types, but would you expect to have to do this for ins and.

E

Strings mean uh you know, the the get value method or the combined get value to serialize on binary data is called two objects from json. I don't think we need to say from json, but one thing to consider is: it could be called two objects of t.

A

Yeah and yes, I think that's again fine if it's a custom tie but like like imagine, you want to just get the like you're standing on the property. You just want to get its value right and let's say it's a number, so you want to get an end. Do you really want to call to object of int.

B

E

You might have an.

B

Array right I mean I I'm not, do you have a two array from jason or two collection or something.

D

No, I think that the object is meant to set system yeah like a dot-net object. I'm sorry g token has a two object by the way like you know, so, there's some precedence to that name. If you wanted to go by the crowd.

B

Yeah, I don't know, I think, good value. um My opinion is sufficient.

E

It could be, I I think it's fine.

H

I have a quick question about the lack of overriding tostring, um so I remember in reading one of the specs there was some question. I think that the stated reason for not doing that was sort of performance because it could be very expensive to have to go materialize.

H

The whole json document, um one thing that we found in our user study when we were testing the azure sdk kind of prototype of this thing was that people liked to use uh what you would call json node in string interpolations a lot like they would make some rest api call get some value back about like the sentiment of a document and then want to put that somewhere and often they would try to compose that with a string using the the string, interpolation syntax, and so we actually ended up overwriting to string and copying the same behavior as json document where, if the underlying value is a string, it's returned without its quotes.

H

um Otherwise for complex objects. We would just json dc or adjacent serialize and give that back, and I'm I'm wondering if, if, if you think that there is value in doing that, uh because it does make it more pleasant to interact with uh for for string interpolation or you think that people will discover like either calling uh get value of string or the explicit cast uh down to string when they want to start uh using this thing and sort of put it in logs or displaying or whatever.

A

Yeah I've I've said this before, like I honestly think, if you have a dom like two string ought to return the you know the materialized form of that. I understand the counter arguments.

A

You don't use two string for things you want to persist or whatever but like, as you said like to me, it's more like a taste argument at this point, because that's just the expectation people have so I would probably do what you suggest and then say I would probably still have actual methods for that, because the other thing we found in some other usability studies is that if the, if the only way you can get the json is by calling two string, people don't discover that because they generally assume two string is not useful.

A

So we'll probably still have a right method or two json string or something like that. But but I would agree with you that if you just throw the object into console.writeline or into string interpolation, it would be nice if the return value is actually. You know somewhat sensible and not just the type name right.

H

Yeah yeah, and so in our prototype. We did have those methods on our analog of json node to like do a string like get which would get string and then we also add cast down to string, um and then we also had the um to to jason string method, because there is a for us. It behaves differently.

H

If the document is a string to jason string would return the string with quotes wrapped around it, because that's what the json document needs to look like, uh whereas r2 string method would return the string without the quotes around it, because often when tostring gets called, you probably didn't want those quotes around anyway. It's just much nicer when you're, interpolating and stringing stuff so yeah by that.

E

Yeah, though, did you guys get the distinction? Our two string and two json string have different semantics.

A

Yeah, no, I get that like it's. Basically, when you yeah when you're in a simple way that is of string, you omit the quotes um which again, it seems reasonable right, because tostring is designed to just look nice right and be sensible.

H

And jason document does that as well: it handles string, especially which we saw so we we felt okay, copying that pattern.

A

So nobody else says something which means either half the people disagree with what I just said, or they all inspire the agreement.

B

It seems like there's a lot of precedence for it, so it makes sense to me.

G

I I much prefer having types where tostring works by default, particularly when interacting with the debugger, because no one adds debugger display attribute and so tostring is the default experience for most types.

E

Speaking of which this type needs a lot of debugger viewer viewers and viewer work, one thing that we we saw in the usability study is kind of users, try to compose json using the mutating apis and they want to always see kind of you know, step through the debugger and see the results, and if you just try it, you will see how it doesn't work super well um today, and it's not just you know you you currently probably don't yet have the debugger viewers, but even the debugger itself.

E

It's not really perfect for this scenario, so we, for example, we're planning to work with the debugger team to to make improvements. We we feel like it's super super important without good debugger support for this type. It's very difficult for users to compose a complex jsons.

A

So what specifically, are you? Are you needing? Because I mean there is a default json viewer already right so like. If tostring gives you effectively a json encoded string, you just have to click on the loop icon and say json visualizer, and it will basically render it as a tree.

H

Yeah we ended up having to to point people essentially to that we we basically ended up telling them hey, set a watch um so that to jason string uh like just set a watch on, you know, value.json string, and then you can get the um uh magnifying glass and do the json view.

H

um I think at the time like that, behavior um the debugger wouldn't show that hourglass, if when it was just showing the like two-string representation of the type, so you had to actually like invoke a method or get a property whose return value was string, not some type who's like when you call to string. It was a string, you wouldn't see the hourglass or the the magnifying glass then um so, there's probably.

B

Some some stuff there, but basically.

H

Christos metapoint is like we had to basically be able to give something like the jason, visualizer and visual studio to these to to basically all the candidates, or they were unable to really wrap their mind around what the shape of the document they were. Building looked like.

A

Yeah, that makes sense, I mean.

H

And presumably.

A

You only use the.

H

Vs debugger right, you didn't use vs code. Probably right, you know we just did our testing in vs in uh vs2019.

G

I also think that the visualization features for the debugger are less well known. um Maybe it's worth doing a blog post on those I'm not volunteering, though.

B

And and what happens in that case, where you have very large json I mean, can I handle you know 10 megabyte json, you know it might take a few seconds to get that data, or should we limit to a certain number of characters.

A

B

You display attribute and then um yeah for the bugger display attribute, I think primarily, but I'm too jason's. Our uh two-string of course has returned the whole thing, but.

A

I mean my honest opinion is that which, if you have 100 megabytes, json I'd rather wait two seconds in the ide and then actually see the whole thing, then wait 0.3 seconds and then only see the top 25 and then have to figure out how I get the rest right.

A

uh I don't know, like I mean yeah, I think if you, if you debug actual ginormous things, I think you know if you have enough ram like fine, if you don't have enough ram, then you know limit your data.

B

Okay, there's probably a little bit of test center on that for sure. But what happens?

B

Okay? So I'm hearing that um we add two string with a special handling for string and then debugger display attribute, which will at least show the same as two string.

E

For us, the most useful thing would be if the debugger was showing the payload that will be sent over the wire. If people use this to uh to compose json- and you know pass to to the azure sdk, which gets me to the next question, how do we let's say somebody passes us one of those value?

E

How do we get a payload that we can send over the wire?

E

um I see you have an api right to, but it writes to utf8 json, and I wonder whether there should be a right to that right, for example, to a stream and then, basically, I would say, debugger viewer should show the exact thing that will be written to the stream when right, 2 is called.

B

Yeah that was well actually, someone else asked for feedback on adding the right methods to a stream, and my comment on that was: we could do that. We have to add four overloads at least four overloads one for each of the four types here and then um actually I take that back. This is that's not a. um It doesn't return anything right to. We just have to add one overload, um but we we don't have. We don't have a way today to write a string I mean in in the you know: utf-8 jason writer.

B

You know we write utf-8. So if we do have strings, um I know we have. You know two-string.

H

B

We already talked about, but we do have to at least talk about how we're promoting utf-8 or our you know, going around in efficiency and having to you know, encode, that from or decode or convert from utf-8 to string.

E

Could you could you explain, I I didn't get it, what is the conversion.

B

Well, internally, utf-8 jason, reader and writer, which everything is based upon here, only understand utf-8 for the most part I mean you know it's it, it doesn't read strings directly. They read, for example, and writes.

E

That way, but I what I was imagining imagine that you add an overload of rights to that, takes a stream and inside the overload. The only thing that you do is wrap the stream in utf-8 json writer and pass it to the overload that you already have.

C

E

C

We'd need to put utf-8 in the name somewhere, because that's.

B

What we would need to do, and- and you can already do this today- using existing json serializer methods- you can call json serializer.serialize and then pass the stream in and we will write utf-8 to that stream. um It's just do we copy that? One uh method, then, here for stream.

E

Yeah again, I don't understand what you would pass to the serializer because serializer it's not enough to call you know, method serialize on serializer and pass the stream. You also need to pass the thing that you're going to be serializing. You pass the node on the stream. Oh so serializing a node will actually write yeah.

B

The node will be treated, um adjacent, node will and derived heights are directly supported by the serializer.

B

H

B

Not something that we had to add extra code for um that's just basic well kind of, but it falls into the custom converter model that we have. For example, if you have a json node property and you on a poco that'll work, you don't have to um you know, have.

H

B

String property and then convert it later.

E

Yeah, anyway, so no matter what whether we add the method right to the try to stream or you know, serialization, what I would love to see is the debugger viewer literally shows exactly what would be written. If this thing was, you know, written to a stream or serialized.

C

So so um two json string are you expecting that's going to be pretty printed or compact.

E

uh I'm pretty printed, which.

C

E

B

E

Nothing exactly not exactly.

B

Exactly if you specify the same options yeah I mean.

A

It's a pretty prim.

B

um Debugger display attribute okay.

A

I mean: is there any reason why we couldn't just do the same thing as to string I mean you, have you have the special case when it's on a string value but like? Are you likely to inspect those at the time? You call right.

B

Too, can you repeat that demo I was that a question for me or well.

A

What's that like, because chris have insisted that it's exactly what's being written, I'm saying like? Is there any reason why the debugger display couldn't do the same thing as tostring, but we have the special handling for simple string values because it doesn't seem like when you have a simple string, radius you're very likely to call right two. So I don't think he would actually observe the difference.

A

But it seems more self-consistent to say. Debugger display and two string are the same thing.

E

Yeah, maybe maybe it's good enough, I don't know matt. What do you think I? I we've seen some users being a bit confused about the whether they have codes or don't have quotes, but maybe it was just one.

E

User, well, what about that you know implement whatever you think is the right thing to do here and we we usability test this time yeah. I think this.

B

Bugger debugger display attribute. We can definitely iterate on that, and I I do think, however, that um the path, property or path method is also useful there. I'm not sure if that would you know if you display two things there, how that messes up any kind of visualizers you might have um if you can have a visualizer for debugger display or if it's only the the two string, but I do think the path property is important, for you know many scenarios, because you might be.

B

Yeah I mean you, might you might be wanted to see a child? No.

B

Yeah because he might be serializing a child note or hovering over child node, and you don't know by looking at the json where it fits sits in in there. So um I do think that.

D

Just play like help in that case, like you, don't really need a runtime property to know that right.

B

Well, it depends.

D

B

You might have a watch on them on an object but yeah as you're navigating down. That part is obviously, if that's what you mean, I mean because you have to navigate. You know to a particular node and then, of course, the json path is fairly obvious. You might not know the string name of a property um in the debugger, but at least you understand, the the levels are the hierarchy.

B

If that makes sense.

B

E

B

Let's, I think we should table the debugger display because, like christoph said, is a lot based upon usability and- um and I think we could- we should get feedback on that before we beat it to death here.

A

So the so just to close on the right two one.

A

So basically, what I proposed in chat was just providing effectively write to with a stream right over the text right and right with jason writer, because it seems that these are the most common types people want to write stuff to, and then I think the stream one probably should take an encoding, because if you said like it's not clear whether it should be utv8 or utf-16, and I would just say you know, make it nullable and then, if somebody doesn't specify encoding, it gives them utf-8, because that's probably the 90 scenario anyway but like if you have a text.

A

Writer like you know, of course, you're getting utf-16 most of the time. But you go through the text by the abstraction. So whatever that thing does.

B

A

B

For the accordion one, that's that's might be kind of a large feature. um I mean we don't do that anywhere else.

A

So you're not doing anywhere else what the conversion from like the encoding conversion.

B

If, today, when you write to a stream, we don't ask you what you want written, we just assume it's utf-8.

A

Yeah, I mean- maybe that's also. Okay, like I care, I guess more about the text writer, because that's the most common type for you know concatenating strings. Basically right because that's I mean you can argue as a string builder but realistically, like the abstraction that you pass around. Is a text writer? No, that's not a string builder um but, like you know, if you just want to basically build a dom in memory and just have it render nice somewhere, like I don't know, text why that seems like the most handy abstraction for that stream.

A

You can also do, but it's a lot more pain in the ass. If you, if it didn't say you just want to get a string out of it, because now you have to do gymnastics of that.

A

It just seems like it's the most common types people ask or pass into dorms.

D

B

um What about the the parse methods? I mean one of the feedback I had somebody. I actually asked for a parse method and that's where I said well, if we add a stream based parse method or read from or whatever we end up calling it, we have to duplicate it four times, perhaps depending upon you know what type you expect back and to avoid cast.

B

If we want to do the same thing for read,.

B

What are the four times? Well, um the parse method, for example, exists on json, node, json value, json, object and json array. It doesn't have to exist on the other. You know it on the three types it could just exist in json node, but then that requires an explicit cast by the user and if they already know what node they want, um you know they could just call jsonobject.parse, for example,.

E

But like just from you know, azure sdk scenarios we.

C

E

Always when we retrieve data from azure, we would always return json node. Therefore the user will always have to cause.

E

Therefore, it seems to me, like just parse method on json node would be enough to me the main kind of complication of using streams. But I I having said that, I I still think that the complication is worth it, but the main complication is that suddenly you need sync and they think of apis, I think- um or maybe even just they think I don't know this whole thing about synchronizing and streams is usually the most complicated part of similar designs that we've done.

A

Yeah, I think, for for the stream one I would assert. We want an async overload. I'm not sure I would only do async, because if you write to memory stream, which you know in many cases, you might end up doing that doesn't buy you anything.

B

Yeah in either case those methods would drain. You know the stream up front during the d serialize and during serialized right a big byte array. In one chunk I mean it wouldn't be, they think um keyword really won't. Do anything re.

E

I is won't you use just utf-8 json reader and the writer inside yeah, which don't which.

B

Don't support async, ah that's right! The serializer supports it. Okay, if you, if you'd, call the d serialize and see serialized methods on the serializer, it has an awesome infrastructure to ask for data as it needs it and write data as it needs it, but internally the reader and writer and document and element. None of those truly support. Async document has a um a way I think, to take a stream, for example, but it drains it up front.

E

Yeah, I forgot, I think now that you mentioned it. I remember.

C

I mean the the yes, I guess parse from the reader yeah. The reader is asynchronous um yeah, the json document parse async, is it asynchronously pre-drains the stream yeah.

E

Reader, I I think I knew that. Oh no, but utf-8, jason, okay, so utf-8 jason writer supports stream natively.

C

uh I think it always supports, like it supports complicated things, but not stream, but it it doesn't require completion. So I think you can drain off the data and keep going, but that could be remembering and.

B

Just for clarity, utf-8 jason reader indirectly supports async, which is how the serializer.

C

B

By getting the raw data out, you can get the problem, um utf-8 json data or whatever it's called get.

H

B

Out and then pass it around as a struct and then um new up a new reader later and invoke it, but but utf-8 jason reader is actually a refstract, so you can't even reference it within the namesync method. You have to do that better.

B

I'm pretty sure some papers or something.

E

Yeah reader, yes, but a writer writer supports streams. It seems that it natively supports them, but I I was in the api.

C

Okay, I guess I'm remembering I thought it only supported give me the span to write to.

B

Okay, um we have about a half an hour left if we want to keep going, it does have stream who knew want to scroll down emma.

A

Yeah I'm right away. My fridge give me a second.

C

Yeah so uh levi pointed out in chat, you know that basically write two that takes a stream. Can it can be utf-8 if we want it to without taking the optional encoding. On the one hand, I think it's a little weird. On the other hand, you know utf-8 is winning if not already won, and it's just that we're in a in a hybrid state, because we've been utf-16 based for so long.

C

So we could have the simple one that doesn't take a an encoding parameter and then add that later for the complexity, that's involved once.

H

C

Us something that's not uh encoding.utf8.

B

Yep I like that. I I think that we can add that later so as an overload.

B

Okay, moving on, then that was json node, there's a bunch of implicit and explicit operators who skipped over those, but that's okay, um json array represents an array and json and um it implements I list of json node in theory. It doesn't have to implement I list, but it's done here, newton's off does it and I believe it's kind of expected.

B

So that's the reason for I list there. However, some of the methods aren't really appropriate. So some of the um I list methods are implemented explicitly and you can just kind of go over those yourselves. So maybe maybe we want to remove those explicit implementations or add other ones completely open. I just kind of did a best guess on that.

A

So what does it mean to call add with an object that is not a json node.

B

I I believe this has to do. um Let me think about that: um how did that.

D

C

B

C

Did you have a json node constructor that took object and then just does magic? Maybe.

B

Maybe I had I originally yeah. I take that back originally.

C

B

Was of type object way way back then, and perhaps it's just a remnant um by the way.

F

We need a behavior like this, so the way I would implement it. No, I know.

E

uh Well, we need the behavior to for users to be able to add objects to uh to json arrays and the scenario is- or we we've seen- users relying on anonymous types. So, basically in in code, they wanted to add. You know a small json object that has two properties to an array and they would just new new. You know open curly property, one equals value property two equals some other value, close paren, close curly bracket.

B

So that, actually, is the reason why it ended up here, um because this I list used to be uh of, I lift the object and not json node, and I forgot to remove this overload for some reason. But if you have that scenario, what you do is you just new up a json value of type object of where t is object and then you can specify whatever you want from the constructor.

E

Yeah does it work, the constructor works with anonymous types yeah, it just utilizes them correct, yeah,.

B

Yep yep, so so this is a typo here. The add of object um ignore that.

C

I mean we could add it in the future. If we have a usability discovery problem, we have an accelerator to do the other thing, but then it probably needs more options like serialization options and the like.

A

Yeah I mean it seems weird to have operations that I'm flickerly serializing, though like that would be the first one right.

E

Yeah, but having said that, it's super useful and it doesn't need options. You know you do it the the reason it doesn't need options is when it's an anonymous anonymous type, the user typing the property in the property name.

E

Can they basically look at the json payload that they are supposed to produce and then they type, for example, common case clr properties, because those are not real, you know types, it's just like you know, inline uh anonymous type, so they they basically type their names as they want them to appear in the payload.

E

Therefore, it worked very well.

C

Yeah, I think that the current suggestion is we get rid of that object. Here. Add it later if usability demands it, but the json value, constructor or static method, or whatever it has, will do that serialization and that that's expected.

H

C

It doesn't have to maintain lazy side effect, mutation, semantics, but.

E

I don't understand if we added, if we added basically kept the overload and the text object and the the thing that we did is nearly we just serialized the object and added it's serialized json node value, it's basically a helper. I.

H

Think it would.

E

Be very useful because, right now I suspect users will not.

E

You know, understand that they can just and and then the code looks also kind of ugly, because you have like array and that add, and you have to do new json node and that bars or.

A

I mean at that point it just becomes a different language, syntax. To achieve the same thing right, you could just instead of calling ad explicitly with the dynamic of a anonymous object. You could just use the object, initializer syntax, which looks virtually identical right.

E

Now for object, serialization, initialization syntax! You need to have a type that represents the uh the you know, the shape.

A

E

A

What json object is right, you would just say new json object, open, curly, brace, and then you would just assign random properties to it. Right.

B

The the shortcut okay, so if, if we don't have object as the add parameter, the workaround is to say new adjacent value of t, where t is object and the constructor takes item I mean there's, you know that that's a workaround there's no object and then, however, you got that object, you could use um instructor.

B

However, you want to instantiate that object. um You can do that. You know before that call.

B

But if we keep the object here, then we add that one line of code that says new adjacent value of object and then with parameter object.

C

Yeah, I mean all the the case where you know you're taking object and you're serializing. uh It comes back to my. Is the user aware what the dynamic type that's being serialized is so that we don't end up with over sharing of data um so that it should sort of look like dc, realize.

A

Well, it wouldn't be done any objects like in christopher's case. It's a it's a strongly typed anonymous object right.

C

Sure, but it takes object and you pass you know whatever our standard example is, you know, person p and it what it actually adds in the graph is employee with their salary, like that's our our classic. Don't let something get written down that the user didn't see.

A

Right, although like I'm, not sure how that I mean, I mean that can always happen right, even if with our apis, he would just say, like you know you basically, instead of saying all right object, you would say, add t and then you would, you have an add of t right and then the user would have to say, add customer right and so or add person or add off person, and then passing.

C

It yeah, and so, if it's, if it's out of tea, taking t items that makes sense to me yeah, it just needs to have the same basic shapes as our serialized does.

E

Yes does does do genetics work with anonymous types.

A

Yes, they do it's just that.

E

A

Yeah they're, just basically I forgot how they're represented, I think, they're a prime b prime c prime and the intellisense id when you when you do that, but they are, but they are strongly typed to whatever. That thing is.

B

But I think for anonymous types, if you're going to be calling or add an anonymous type, I think you just specified object as the t parameter well. But if it's.

C

Add of t t item uh then, then the t is specified for you by generic input right right, generic yeah sure, yep.

B

If you have, um unlike the constructor, um which doesn't support that right.

A

Yeah, so that's true like we need to make sure that it can always be inferred right. So constructor of t wouldn't work for that reason. Right because now, you're screwed.

B

Yeah and actually there is, uh we've got to adjacent value later and there was a proposal having a factory method that ever did generic inference. For that reason,.

E

By the way, one thing that I promised steve yesterday and I still plan to do it- um is send you guys some kind of common json payloads that people want to send to azure, and I think it would be good to write usage samples that show how would user use these apis to compose these jsons.

E

uh I kind of noticed that I don't know. Maybe I had the first review you reviewed usage samples.

E

I think it's very important to write them for this api, because some of the json apis that you know frankly, we shipped- and I I partially designed they kind of look so busy in comparison to what users want to write and what is possible with nice api that supports, for example, anonymous types that I think it's super important to write, few usage samples for those common scenarios and uh one additional node, which is kind of when you look at the api, it's very easy to imagine how they would be used to compose an object with bunch of properties, but in real life.

E

Many of the azure payloads contain arrays and especially like producing json that contains arrays or like outer object, that has a property that is an array is super like busy and it's very difficult to read the code. Unless you know the apis are kind of designed for for. For this scenario,.

E

So I I will send steve the the json payloads and I would really strongly recommend that you kind of write these samples and see whether you like it or not.

B

Okay, yeah- and I there are some samples later in here, but I mean they use a combination of constructor, initializers, implicit and explicit operators. I don't think I have any that use anonymous types, but I could add that depends on how how many of those features, you think, makes sense.

E

Yeah and usually, basically what in real scenarios what happens is the user has the data in some data structure, but it's not so now they have to kind of map this data structure to a json payload, so they read the rest apis and they see that you know they need to pass an array of some objects and uh what they actually have.

E

The data source is not exactly the same shape, so they used most of the usage samples and the code that people want to write is basically a transformation from some some shape that they have to to this json payload and and again, as I said, some of this code looked super super ugly.

B

Okay, where do we land in on the ad does having an ad of t make sense for things like anonymous types, or should we not do that for now?.

E

If reference, if generic parameter inference, what reference inference.

H

E

I would really love to have this method, because.

B

Because the alternative is to new up the json value in one way or another, probably for anonymous types, you'd have to add the factory method. That's not quite proposed yeah. Why don't you? Can you scroll down a little bit to hit json value.

B

So yeah here's the abstract class- and I have a comment in here that says, um if we add a create method here, you won't have to specify the t which, with anonymous types you pretty much need to do that because you don't know what type is being generated yeah. um But if we had this create method here the the work around, then you basically call this static method and you pass in your anonymous type and then you pass that into the existing add method that takes a json node.

E

Yeah users don't find static methods. I mean it.

B

E

It is an option, but again I would say what is the negative of adding add that takes. You know out of t and if there's no negatives, that we can articulate, let's just add it, and then we don't have this problem with users, not finding uh a static.

A

I mean if we do it, we should have an overload detects options.

C

We could, or we could say once you're doing something other than the default options. Then you have to go through the longer or the more verbose path.

E

And but honestly again I would say the main usage for this method is anonymous. Dives and the moment it's an anonymous type. The user can just do casing whatever they want. The json payload to end up be that they change they face.

C

Yeah, I mean the only thing that I sort of wonder with it is. I know that ad is really the verb that we have here, but does it should it be something like add, serialized or something to indicate we're reading it and serializing it right now we're not holding a loose reference to your object and we won't see further mutations.

C

Okay, you, you actually are holding that raw value.

F

When you do that, so you're not serializing it yet you're serializing it at some point later by the way, one one of the kind of principle that we were going after when we were designing.

E

Our type was: can we get the c sharp code to be as close as possible to what what she would do in javascript and the moment you keep adding, like you know, add serialize and whatnot. It starts looking like very busy api and not like javascript.

C

Well in but in javascript you do have a a reference that is held there, and if this is holding the reference, then we can do add, and then that becomes the behavior for all time, like once you're allowing a a modification of the object after the call to add to show up in the graph. That's that's now the behavior. Maybe I misunderstood.

E

What you were saying I I I was, I understood as you saying, don't name it with a short name, add but name it ad, serialized or something you know like make. The name.

C

I thought I thought ad was taking the object, serializing it immediately and then building the tree as a result of that meaning, if you call to add on immutable reference type and then or passing an immutable reference type and then mutated, that reference type that will not be in your output json later, but then steve said it is holding a reference, so add actually makes sense.

A

Well, I really can't right because it implements a list of json nodes right, so it can't hold on to whatever the dynamic object or.

E

A

E

A

Type was, but it has to convert it to a json node immediately.

B

I mean it wraps it it just wraps the instance.

B

A

Because you're holding on to it on the.

B

Json yeah it's for one liner, that says new json value um and passing the object. The type might be object. If we don't know the t, I guess, but so the t here is can't.

C

Be used for type limiting serialization, so this is a. This is a complex polymorphic, serialization scenario.

B

Well- and you know what we could argue, we could go down that path of um saying we should do that, but in a lot of cases it's not necessary because during serialization of course it's going to write it out, as you would expect, it's only necessary if you want the in-memory dom to be perfect right, have all the notes expanded and you can look at each one and and say hey this. You know it's no longer a poco instance or whatever no longer a customer poco.

B

It's now a json note of you know individual properties based upon that. But then that adds some extra overhead, of course, because we have to deserialize that cocoa into adjacent node and then probably for nothing, because we in the end we're just going to serialize it as a string.

C

B

Byte array yeah.

C

So I guess to back up on my thing: it is if it's generic here, we can still capture what the t is and hold it with the json value to know what to serialize it as later, so that.

D

C

Bounded serialization add an object here, so if I call add with an object and then I look at the children of the current node I'll see a json node, but then when I ask that what it is, will it say it's a value even though it's even if it's a an object like I can't walk the children now.

B

Yeah yeah, I do. I do call that out somewhere in the design here that um it's like, I said, it's kind of a trade-off. It's like. If we want to take the hit to desertalize everything and to have your perfect memory dom we could do that. We could make it an option right, we could say: hey, you actually want to do a de-serialized which you could actually um anyway. I like.

B

I said I it's more of a performance thing, because we just allow you to assign anything you want, even if it's an object or an array. Normally you use adjacent object or json right to do that, because you don't have an existing poco type. But if you do our existing array, but if you do have an existing poco, our collection hanging around and you just want to serialize it- you can.

D

Assign it and then that.

B

We do have to support that. I think in general for um our the assignment portion of it in general because of things like dynamic but yeah. If we want to auto convert, that's not done today. If we want to auto populate a json object in json array based upon a clr typing passed in it's not done today, we could make, we could do it, but I think it should be perhaps an option.

A

I mean that seems reasonable, but also confusing, because it basically means, if I take a given json node and I effectively to string it and parse it. The resulting dom that I get back is not the same that I was holding on to before right.

B

A

H

B

String, it does a serialize which will invoke the serializer to serialize your poker.

A

Right, but if I pass this back, I don't get a jason vader. I get a json object when this thing was an actual complicated object, graph right so like the actual.

B

A

Of the dom is different.

B

The structure of the dom is different. The value of two string would be the same.

A

Yeah the two strings, yeah yeah, two string will always be the same, but the the dom structure is different. I mean I'm wondering whether we can just do the the lazy thing differently and saying. If you give us a t, you know unless it's a primitive, we always make a json object out of it, because well that's what it is.

A

And then you know, if you ask that for children, then we will, you know implicitly desiralize already, because then you can treat the dom as the same right and so people just assign stuff, and they just you, know, visualize it later. We don't. You know, pay for the instantiation of all these object graph elements, but at least the complexity is out.

A

It seems a bit weird that if you added you know an ad of a dynamic object and then you ask for its children, you basically say nothing, but then this thing actually had children or properties right.

A

You know what I mean like it like. It seems, like you're kind of you know, you're exposing.

C

The fact that it's.

A

The first year that it's deferred dieselization, basically.

C

Yeah, but that would get very complicated, because can you now write back to the original object through those json nodes that it returns like give.

H

C

Serializes at the call to add, then you can make sense out of all of that and you can build the tree and if it's holding a weak reference then like. Maybe it just means that we need another type to indicate that there's a deferred serialization going on here like and maybe json value of t. Does that because it's it's either one of the built-in values that is being deferred serialized into the obvious thing or it's a deferred serialization of a thing. So it could be that we already have the right.

B

Semantics I mean if you have a json um object or an adjacent array. You know it's a well-formed, you know um node or dom. At that point you could still have a value within there a valuable property of an element. That's not, but in the end, when you serialize it you're going to get the same result um so.

C

Yeah, you mentioned the the perf advantage of delaying the serialization, but in if you're in the debugger, it's actually going to be worse to do delay. Because every time that you hit this debugger display you're going to dynamically serialize the object. Then you hit f10 you're going to dynamically serialize it again because you're not saving any of these values, and we really don't want f10 to modify your tree because woah is a bug.

C

So in non-debugger scenarios and places where no one calls two string, it's probably a perfect improvement in in cases where they do call to string or use the debugger, it's a cost. So there are trade-offs. Sure.

A

Yeah, I think, for the debugger. It probably doesn't matter right, like I mean you're, not calling this in a tight loop in the debugger anyway, because then everything is slow. So I think the debugger scenario I can. I can buy that we pay in overhead, but I also by the scenario that in the most common cases where people basically compound the dom, it makes sense to defer the digitalization. It's just it's slightly unfortunate that it's not an implementation detail right. It basically leaks into the way you use the dom.

B

This is also consistent with newtonsoft fyi.

A

They do the same thing: they basically have a wrapper type and then a different visualization.

B

Right, yeah, you can assign a value or an array to it, for example clr array and then that's preserved. That instance is preserved. Yeah.

C

Like it, it does lose in a little bit of purity to me, but um but I I expect that most people are using the trees as either I loaded a thing and I'm modifying it. So.

H

C

Already done all my reading before I start my writing or I'm writing it from nothing. I.

H

Think it's probably weird.

C

That people are really reading these things very much after they start writing these things, so it it probably won't come up much.

B

And if somebody did want to completely normalize node graph, they could of course serialize and deserialize and get back. You know a well-formed um graph wrong.

C

What happens if you call the jason value constructor and you give a value kind that doesn't make sense.

C

Like I, I give you a rich object and I say json value kind as number.

B

Yep, that's um that's a good question. I right now the that value kind is informational. It's not really used by any of the json node stuff it during decentralization will respect what you know. The json element had, um but really it's informational, so nothing it. Ultimately, I think, for example, when we it might be used.

B

If we want to support something like comments, xml comments which are not supported, then you would set json kind. I think, to comments, but still you know, assign a string and then it would be used, but right now it does nothing. um I I at least I haven't documented it anyway. I haven't wrote the xml doc for this, but I imagine it would not do anything I mean unless we call it all, then it.

C

Seems like we should get rid of.

B

It it's it's, not it's not really needed. If people are curious, um I mean it should be obvious what what the jason node type our kind is, and if we want to support xml comments, there might be other ways to specify that said. You know this given node is a comment and not a a string.

B

I'm okay with removing it.

A

Here it came of removing which part.

B

On the jason kind.

C

A

Oh, the kind property um and.

C

The non-defaulted parameter between two defaulted.

B

Parameters and there's also a json kind property on json node. That's, I think, just a getter that would probably just perhaps want to remove that as well.

C

A little bit that one is an alternative to casting to know what kind of thing you're looking at.

C

B

The weird thing.

C

Would be here if you pass in I'm I'm an array and your adjacent value, and then you say great. That means I can safely cast it to json array. It's like haha no, you can't yeah. The thing is uh because.

B

Custom converters can be specified, you can have um adjacent value kind, might be anything right. You can write an integer out as an object if you want. So that's why I say this yeah. Perhaps what we could just yeah remove the adjacent value kind um argument from this constructor then.

A

Well, but what would you return, then,.

A

A

So you basically would make the kind property on jason, not another, building.

C

A

Zero value.

C

Is I don't know what kind of thing this is right.

A

Already has an unknown.

B

Kind unspecified would be the default value, which would be the d, which would be the value for every new node that you knew of.

A

When, at that point, like does this property, add anything like what would you do with it, because they're kind of even.

C

C

You know doing his checks is the way to go, but uh if you've loaded the thing and you're looking for go, find me, the arrays, then uh reading of an enum is faster.

A

Right but like that goes back to your early argument right if I write a switch over the value kind, I don't know what what do you do with one specified sentence you just blow up. I don't know I.

C

Mean unspecified would only really apply to adjacent value types uh if you've got it from a dc realize that that wouldn't apply.

A

Yeah, I know that no, but like would I know this when I write this.

C

Yeah, it's fair. We can get rid of it.

C

I'm clearly of two mind.

B

Okay, we're hey we're running short on time here, seven minutes! um This is jason's value jason. um Can you scroll up a little bit just to make sure we hit um hit everything, I'm not sure what we missed yeah.

H

I don't think we.

B

Missed anything then um jason object implements. I I dictionary similar to jason array and there's.

C

So the only real question that I have that I haven't heard an answer to yet is um on jason node. You put the numerical indexer and the string indexer. I think. um So. What is the behavior of those for when it's not the right type,.

D

B

I should probably document that here I mean like I said I didn't write the xml doc, but it will throw in valid operation.

C

And we think again, this is just based on you know, having learned from jason element that it surprises people. uh Do we really think that the them being on the node people find more useful than they find confusing, because with json element we basically learned they find it confusing?

C

What's the alternative to that, the end index are only beyond json array, and the string index are only.

B

C

B

Yeah, um can you find the section that talks about that? Let me see. Let me pull it up locally here again, because I have some code examples of.

B

C

Like I can believe that we think that these two things are more generally useful on the base class, and but I know that I've heard a lot of grief since we had a json element of okay. The index is here, but it doesn't work and why? How was I supposed to know that it's like? Well, it's a complicated union type. You have to ask it what kind of thing it is. Okay, my doc is on.

B

Line 698, but if you search for.

A

B

You do a spiritual, ammo.

A

B

Search for um adding.

B

B

Another one trying to try the next hit um three, it should say adding json, node, indexers or search for index or maybe sorry just search for indexer or indexers plural. Oh here we go.

A

Isn't that the one yeah? That's what I call it.

B

Oh okay, sorry.

A

B

So this just shows an example um and actually the feedback here came from the azure sdk team, because they do you know they have a single single type, but here's an example of having to cast um and find the right types in order to.

C

Navigate, I mean yeah like it. It functions.

C

uh I'm just surprised. Like again, my my feeling, based on jason element, uh is that it's one of the things that people hate about it that that it has these members that are in your face that you can't use.

C

So maybe we need to just come up with a good case and a usability study to find out if we can really make a decision of whether they're, uh helpful or a hindrance.

A

So is it semantics basically, the first time you use the indexer on an on an object and you use the in-based one that means you're implicitly making it an array.

C

Well, I think it's it throws unless it is a json array right, it has to be an array right, yeah.

H

C

The virtual is throw and only json array overrides it to do something useful.

A

Right but in your case you're, never calling ad right, so presumably indexing implicitly doesn't add right.

B

A

B

Assistant only um so here it won't automatically add.

A

So how does this work then, because, basically, you just created the object out of thin air. So how can you index into it.

B

I I I um oh good point um it should. If this I I I put the new jason object there, I shouldn't have did that. This is just a um an override scenario.

A

I see so like it basically already has to have a property called char. The property called array.

B

B

um After after array you call dot, add and then you, you know, specify something there and then you have another line that changes it but yeah. No, I need to fix that. That's good. I mean.

C

I assume people will want dictionary like semantics, so they can assign to an unspecified property to create it.

B

C

B

Is different, um the the string indexers is: oh wait: yeah, sorry, yep, yep, jeremy, you're right that this does do an ad. I I was just thinking that it just did the raw zero there, uh which would thrill, but in this particular case it does work. It will call add just like the dictionary indexer.

E

Does already, this is one of those scenarios that we should write a real code sample and make sure that it works and it it does what users expect, because uh one of those usability problems that we observed is that people didn't know how to create. Basically, a very common scenario: is you have an object?

E

It has a property and the value of a property is an array, and now the users didn't know how to create an empty array, so they can keep adding to it and they thought they need to specify size of the array, because array in.net is something that has a fixed size. So when you instantiate it, you have to specify the size.

E

Well in json array is not really a fixed size thing, you can kind of keep adding to it. So that was very confusing and then I think your api is slightly better actually than what we had, because you have a type that represents array we didn't so in in our prototype, the user would have to either call a special api that gave you like a sentinel value that represents, you, know an empty array or an array, or they would have to use like object array which was not super intuitive.

E

You have a type, but the problem that I think you have is this type doesn't have a default constructor.

E

So I'm pretty sure that users will be wondering okay, I want to create a property, and I want the array to be initially empty and then keep adding to it, and you don't seem to have a constructor that lets people create an empty.

C

Array, no, I mean, if that's, if we're just missing default, constructor json array, then that's easy enough to add yeah. It.

F

May it may be so that I mentioned basically.

E

This is just you know, the tip of the the iceberg. There are so many of these kind of things that uh I suspect will be pro problematic.

E

So one of those is just you know, creation of an empty array, but the high-level point is: we should write lots of samples that are real code samples for producing json payloads. That users will want to produce.

B

E

B

One is broke like I mentioned, on, for the indexer portion, but on a read scenario. This would be fine um or or when you're resetting an existing value would be fine but yeah. You can't just automatically say index of one and assume we're going to call add I mean we could we could allow that, but that's a little goofy, because if you have a bunch of gaps or something right, I.

C

Mean that it does work in javascript, where at least my recollection of javascript is, if you use a thing that is implicitly in it or an integer, uh then it makes an array and default sorry it. uh The undefined fills everything with a lower index and.

E

Again, this is the same thing we if we don't have this supported people will not know what to do because they will first, they will not discover that this method add because of the confusion that I mentioned, the thing is called the ray dotnet developers. Don't think that array has a method add, so they.

H

E

Find the method add they try to use the indexer and then first they think that they need to instantiate an array with the right size, and then they actually expect the indexer to work.

C

You could call it json.

E

C

But then that's probably different.

B

And in fy we don't have the um optimization that we specify the the length of the array. I don't think I added that to jason ray so I I think azure sdk does have that. So that might be related to part of that confusion.

E

But I I think big part of the problem would not all problems, because our usability study was not super successful. I have to say in terms of like we are not super happy with the api, but I would recommend that you try to make the indexer as ad working people will have a loop. They will try to basically in the loop, read some values from a store that they have as I mentioned, and then they have an indexer of the thing that they are reading and they want to use the same indexer.

E

To now add items to to the array. I.

C

Think doing set of count, meaning add, is has reasonable semantics doing sparse backfill feels like it'll be complicated, uh but.

B

I don't know method would just return the object you passed in, which would allow you to call add and then continue with the dot syntax.

A

I mean kristof: are you basically saying that you want for an array almost like dictionary semantics, where the key is the index, because I mean that's what you would have to do in a loop right.

E

uh Er exactly what you, what you're saying but think about it. This way people see a type called array.

F

E

They think that it behaves like array, and how do you use an array you instantiate it? You pass the size to it and then use the indexer to assign values and that's how they will want to use this type. And if you don't allow them to use this type, it will be a relatively large stamping block.

C

Yeah and like I think that it would make sense, and I mean we could debate whether we wanted to do this for a list of t that if you are doing sub count that that is like. Oh obviously, you just want me to call ad, but that, if you did, you know if you the first line, you did was array of one equals something it's like. But I don't know what to make zero like.

C

We can write null, but is that what you meant, and so.

B

C

Wouldn't let them as long as they're writing from low to high index. I think that we can make the loop work fine, but if they want to write high to low they've, somebody's got to do something, and that seems a little weirder and like it's just figuring out what the state means.

B

E

I mean we could.

B

Add the add method to jsonnode right and then just return. The t value.

A

I mean, I think you could say, like json array could just take. You know an optional argument of size right. So if you specify that let's say you say 12, it just means you immediately have not just capacity 12. You also have 12 null values in that array already so now, when you actually index into it, 0 to 11 are fine valid indices. If you say 12, you get an outer range because we don't have that yet.

A

But if you call add it's finally get a 12 element or a 13th element, I get that that one seems naughty, not unreasonable. Right.

C

Yeah I mean so like we just yeah need to figure out what the semantics we want, maybe maybe null filling the previous values is totally fine, but um but yeah anyway. So to kristoff's point and what I was bringing up. Yes, we need to understand some samples, so we can determine if this is uh helpful or harmful and um because I just feel that my recollection is this is one of the things on jason element that people found kind of infuriating.

C

It's like intellisense said I could use this thing. Why couldn't I do this thing.

B

We could take this offline and we're out of time anyway, but I I'm curious jeremy. What what would be alternative on jason element? Would you get some kind of a new type back or what? What are you thinking there just so I have that.

C

Jason element can't do anything because it has um I mean unless we we now went back in time with kristoff's uh thought of you have strucks that you just have to static cast to and all that they're really doing is reinterpreting uh the same thing. But um since you have polymorphism here and hierarchy, it's these indexers could only be on the types that they're available to. Yes, you have to do more casting, but it's it's not that you feel that intellisense is now lying to you and saying something's available that wasn't.

B

And- and I do think the example I have down below could be fixed up a lot in the sense that you could have like a dot as method right, because the problem with casts is that they're front loaded and if you could just inline everything um and make it natural, then that would um you know you could think about it that way, right.

C

So anyway, that's just where we need to come up with what we think a reading sample looks like a writing. Sample looks like and and things and just figure out what the right shape is for the right problem.

A

C

A

Alright, so I think I've taken a lot of notes now. Let me find the pr again here, uh which no means I need to click on this guy here, which now will probably take another 20 minutes to load, um yeah I'll post the comments and then it seems like we need at least one more review.

A

um One action item I've recorded is basically christoph giving us some some sample code on um uh like payloads that people want to pass to the azure sdk, and then we can look at that, and maybe that's how we should start. We should actually just as jeremy suggested, just have samples for okay, like here's, some pedals, you want to construct, so we probably have to somehow manufacture that there will be a writing scenario.

A

We probably want one scenario where we just manipulate something we or we already read. We just want to you know fast. You know fuzz with it and then one pure reading example, where you know you just index into stuff and you know, traverse the tree and whatnot, and that would give us probably a good read on how we like the api.

A

Does that make sense.

B

Sounds good. Thank you.

A

All right add what I just said, and then I think we can call the good.

A

um So action items.

A

A

And existing payload.

A

And one sample for.

A

A

All right so then, I think this is it and I just mark the api. It needs more work.

A

And then, basically, um once it's ready again, we can set up another review and then we go over. That again.

A

Does that sound good, my ticket is yes, then I say thank everyone and then yeah have a nice weekend.

C

Thank you, and you know rest of the week.