I'm working on adding the following sections:

• Design choices
• Implementation details
• Open questions

I have lots of thoughts on this. What is the best way to communicate? Will there be a design meeting to go over the API?

I have lots of thoughts on this. What is the best way to communicate? Will there be a design meeting to go over the API?

We don't have the specific date yet, but the API review meeting is planned to be organized in August after more functionalities are implemented. We can probably also organize a smaller meeting earlier or discuss some issues on github. @ericstj ?@terrajobst ?

I have lots of thoughts on this. What is the best way to communicate? Will there be a design meeting to go over the API?

As @kasiabulat pointed out, the idea for now is to start working on the implementation with the API that she has worked on so far and has been reviewed by a small set of devs from the .NET team. Also as she pointed out the idea is to have an all up ApiReview for this project around August, to which we were planning on forwarding that invite to you in order to get your input.

If you have concrete feedback of big pitfalls that we might be running into it would be valuable to point them out now, and we can discuss anything else during the API Review in August. Does that sound good?

I think the main thing to consider is whether nodes track there own position in the JSON graph. That allows for properties like Parent, Next and Previous.

It adds some additional work. When a node is added to a parent (e.g. adding a JsonString to JsonArray) then you need to check if it already has a parent and make a copy if it has.

On the other hand it makes other things easier. You never need to worry about querying or writing JSON when someone has created a recursive loop:

JsonArray a = new JsonArray();
a.Add(a);

string s = a.ToString(); // Explode

Its a big design decision you need to make.

I am merging it and I will create a PR to main corefx.