Tough I did suggest simdjson I was under the impression that it has writer functionality too.
I think just having rapidjson would be enough, having 2 JSON libs (or even 3, not sure if we're dropping json-c) is too much.

Tough I did suggest simdjson I was under the impression that it has writer functionality too.

I think just having rapidjson would be enough, having 2 JSON libs (or even 3, not sure if we're dropping json-c) is too much.

Okay, I can rewrite (parser Part) it using RapidJSON, no problem.

Tough I did suggest simdjson I was under the impression that it has writer functionality too.
I think just having rapidjson would be enough, having 2 JSON libs (or even 3, not sure if we're dropping json-c) is too much.

Okay, I can rewrite (parser Part) it using RapidJSON, no problem.

May I ask? Have the point to do new functions? Or it's better to replace exists with breaking compatibility on new version? (Exists functions has bug from their implementation)

Tough I did suggest simdjson I was under the impression that it has writer functionality too.
I think just having rapidjson would be enough, having 2 JSON libs (or even 3, not sure if we're dropping json-c) is too much.

Okay, I can rewrite (parser Part) it using RapidJSON, no problem.

May I ask? Have the point to do new functions? Or it's better to replace exists with breaking compatibility on new version? (Exists functions has bug from their implementation)

As discussed earlier, we have decided to create an additional json.decode and json.encode function to maintain backward compatibility for the current ones. For example: toJSON function returns JSON as an array, while we expected an object.

The other bugs, aside from returning as an array, have been fixed using the new parser.

Link to the discussion:
https://discord.com/channels/801330706252038164/801411628600000522/1192934310622269581

I'm closing the draft, so feel free to review. :)

PR was compiled and tested on Windows 10 x64 and Linux Debian 11 (ARM64).

I'd advocate moving rapidjson to a submodule
Not sure what other's think

I'd advocate moving rapidjson to a submodule

It looks like an universal way to make dependency. I like this idea
Pros:

• Updates are much easier.
• You can see changes in the submodule from your git client.
• It's much easier to updated submodule
• Less premake5 scripts. So we can switch to cmake in the future.
• Download speed is better for updates
  Cons:
• Slower when repo is used first time.
• 3d-party repo can be vandalized/deleted. This point is valid for premake modules too.
• CI/CD should be prepared for this.
• Submodules can be used only for git submodules
• Can't be used for prebuilded libraries (CEF)

rapidjson is not under development ( last commit was 2 years ago ). I think we can keep sources in our repo.
@znvjder you have sources in the repo and you download them at the same time. I suggest you use only one option.

I'd advocate moving rapidjson to a submodule

It looks like an universal way to make dependency. I like this idea

Pros:

• Updates are much easier.

• You can see changes in the submodule from your git client.

• It's much easier to updated submodule

• Less premake5 scripts. So we can switch to cmake in the future.

• Download speed is better for updates

Cons:

• Slower when repo is used first time.

• 3d-party repo can be vandalized/deleted. This point is valid for premake modules too.

• CI/CD should be prepared for this.

• Submodules can be used only for git submodules

• Can't be used for prebuilded libraries (CEF)

rapidjson is not under development ( last commit was 2 years ago ). I think we can keep sources in our repo.

@znvjder you have sources in the repo and you download them at the same time. I suggest you use only one option.

Generally, Git submodules are a matter of debate. They have their pros and cons. Certainly, for individuals who are inexperienced or starting their journey with coding and compiling project, it can cause a lot of trouble.

The rapidjson repository is forked at this link; it was created two years ago during the creation of a pull request for discord-rpc. In the official rapidjson repository, the last commit was a month ago.

I’d like us to make decisions about submodules together.

Keeping sources in this repo makes PRs like this a mess.
There was some Discussion about them over at DC, but I can't find it anymore.

I’m aware that reviewing such a pull request with attached sources can be problematic and challenging to preview. I’ll try to move rapidjson to submodules today if I can and if permissions allow.

Additionally, I’d like someone to check the permissions in advance because I can’t respond to reviews as they go into a pending status.

I'd have to fork it into the mta org first I think, because premake has to be added.
But wait for the response of other members too, see what they think about using a submodule.

I'd have to fork it into the mta org first I think, because premake has to be added.
But wait for the response of other members too, see what they think about using a submodule.

We have clone of rapidjson repository in MTA project already.
I think, premake must be added in the mta-blue repo and the original therapidjson repo must remain untouched. This significantly helps us with updates.

Any updates on this?

When will this get merged?

Would be nice to have

Bump?