Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve JSON support #32

Open
watkipet opened this issue Dec 14, 2020 · 5 comments
Open

Improve JSON support #32

watkipet opened this issue Dec 14, 2020 · 5 comments
Assignees
Milestone

Comments

@watkipet
Copy link
Collaborator

2.0-alpha has some example support for JSON.

  • Strongly consider using a library instead of rolling our own. Every line of code we write comes with maintenance cost. Consider using a library that doesn't assume a particular development framework (such as Boost, Qt, or GLib). Consider using a library that is available in most package managers such as nlohmann-json or json-cpp.
@watkipet watkipet added this to the 2.0 milestone Dec 14, 2020
@der-stefan
Copy link
Collaborator

I agree partly - having a short dependency list might overcome maintenance cost. Writing JSON files from an associative C++ array is quite easy. The difficult part is a failsafe JSON input parser indeed.

@hoche
Copy link
Owner

hoche commented Dec 14, 2020

I would be loudly against Boost, QT, or GLib for a JSON parser. To me, Boost is one of those things you commit to or you don't - you can try to just use the headers, but you invariably end up pulling in more and more of it. QT is great for GUI apps (I use it all the time), but this isn't a GUI app (although we've talked about a wrapper) and I don't see that we should pull in all its framework just for a JSON parser. GLib...kinda the same thing; you either commit to writing a GLib application from the start or you don't, but you don't really just pull in bits of it.

I've used nlohmann's parser before and it's pretty good. Its main drawback is that there's no SAX parser, which might bite us if we want to handle some sort of streaming input in an efficient manner. It is, however, pretty up-to-date. I've also used RapidJSON, but it doesn't seem to've been updated in awhile. Maybe it's just stable enough that it hasn't needed it. It is fast, though. jsoncpp also looks ok - it's pretty lightweight but not that fast and I don't know how robust it is.

@watkipet
Copy link
Collaborator Author

I would be loudly against Boost, QT, or GLib for a JSON parser.

I seem to recall you stating this elsewhere (in the contributors guide, perhaps?). I totally agree. That's why I stated:

Consider using a library that doesn't assume a particular development framework

@der-stefan - Would you like to assign this issue to yourself? After this discussion, how do you feel about learning a 3rd-party library versus writing one yourself? Just keep in mind that if we write one ourselves, it should ideally someday:

  1. Handle malformed and malicious input
  2. Have a test-suite validating the item above
  3. Be maintained for future JSON capabilities
  4. Be documented

@hoche
Copy link
Owner

hoche commented Dec 16, 2020

Oh, sorry. I misinterpreted what you wrote.

@der-stefan
Copy link
Collaborator

Gosh, I also had understood it the exact opposite. Sorry. It is a good idea to have a lightweight library that can be distributed along with splat.

@der-stefan der-stefan self-assigned this Dec 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants