Support for JSON in wxWidgets?

[Eran Ifrah]

Hi,

For couple of years now, I found myself keep writing wrappers for parsing and writing JSON objects for my usage with my various wxWidgets projects.

I would like to suggest adding an official support for JSON in wxWidgets (and I am willing to implement it)

I wrote a thin wrapper (which I found very useful) around cJSON API (https://sourceforge.net/projects/cjson/)

You can have a look at my wrapper header file here:

https://github.com/eranif/GitLite/blob/master/GitLite/wxSimpleJSON.h

What do you think?

--

Eran Ifrah,
Author of codelite, a cross platform open source C/C++ IDE: http://www.codelite.org

CodeLite IDE Blog: http://codeliteide.blogspot.com/

[Igor Korot]

Eran,

On Wed, Mar 23, 2016 at 9:08 AM, Eran Ifrah <eran....@gmail.com> wrote:
> Hi,
>
> For couple of years now, I found myself keep writing wrappers for parsing
> and writing JSON objects for my usage with my various wxWidgets projects.
> I would like to suggest adding an official support for JSON in wxWidgets
> (and I am willing to implement it)
>
> I wrote a thin wrapper (which I found very useful) around cJSON API
> (https://sourceforge.net/projects/cjson/)
> You can have a look at my wrapper header file here:
>
> https://github.com/eranif/GitLite/blob/master/GitLite/wxSimpleJSON.h
>
> What do you think?

+1.
Might be useful for XRC system...

Thank you.

>
> --
> Eran Ifrah,
> Author of codelite, a cross platform open source C/C++ IDE:
> http://www.codelite.org
> CodeLite IDE Blog: http://codeliteide.blogspot.com/
>

> --
> To unsubscribe, send email to wx-dev+un...@googlegroups.com
> or visit http://groups.google.com/group/wx-dev
>

[Catalin]

wxJSON was (is?) also a reasonable implementation.
http://luccat.users.sourceforge.net/wxjson/

http://wxcode.sourceforge.net/components/wxjson/


Regards,
C

[Eran Ifrah]

On Wed, Mar 23, 2016 at 3:49 PM, 'Catalin' via wx-dev <wx-...@googlegroups.com> wrote:

wxJSON was (is?) also a reasonable implementation.

​I am aware of this implementation, never liked its API...

​

 

http://luccat.users.sourceforge.net/wxjson/

http://wxcode.sourceforge.net/components/wxjson/


Regards,
C

--
To unsubscribe, send email to wx-dev+un...@googlegroups.com
or visit http://groups.google.com/group/wx-dev

[Vadim Zeitlin]

On Wed, 23 Mar 2016 15:08:48 +0200 Eran Ifrah wrote:

EI> For couple of years now, I found myself keep writing wrappers for parsing
EI> and writing JSON objects for my usage with my various wxWidgets projects.

Why is it necessary to wrap anything? I just use whichever external JSON
library the project is using together with wxWidgets.

EI> I would like to suggest adding an official support for JSON in wxWidgets
EI> (and I am willing to implement it)

Thanks for offering it but IMO this would only make sense if there were
some real advantage compared to using another JSON parser. E.g. maybe
integration with wxAny? But I'm not really sure if this makes sense

EI> I wrote a thin wrapper (which I found very useful) around cJSON API (
EI> https://sourceforge.net/projects/cjson/)

I've never used cJSON but I seem to remember that when I looked for a JSON
parser the last time, I saw several mentions of bugs in it, so I'm not sure
if it's a good choice. I mostly used RapidJSON personally and I didn't have
any problems with it. Being header only is pretty convenient too as it can
be just dropped into any existing object without any problems.

So for me the question is really: what's the advantage of having JSON
support in wxWidgets itself compared to just using RapidJSON (or maybe
another header-only JSON library, it's not the only one)?

Regards,
VZ

[Eran Ifrah]

On Wed, Mar 23, 2016 at 7:03 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:

On Wed, 23 Mar 2016 15:08:48 +0200 Eran Ifrah wrote:

EI> For couple of years now, I found myself keep writing wrappers for parsing
EI> and writing JSON objects for my usage with my various wxWidgets projects.

 Why is it necessary to wrap anything? I just use whichever external JSON
library the project is using together with wxWidgets.

​Why not? the C API is not that great... and given that wxWidgets is a C++ library...

​

 

EI> I would like to suggest adding an official support for JSON in wxWidgets
EI> (and I am willing to implement it)

 Thanks for offering it but IMO this would only make sense if there were
some real advantage compared to using another JSON parser.

​cJSON *is* an external wrapper - not my own implementation, I just wrapped it with wxWidgets style API  (e.g. use wxString, wxArrayString etc)

​

 

E.g. maybe
integration with wxAny? But I'm not really sure if this makes sense

Totally forgot about this class

​

 

EI> I wrote a thin wrapper (which I found very useful) around cJSON API (
EI> https://sourceforge.net/projects/cjson/)

 I've never used cJSON but I seem to remember that when I looked for a JSON
parser the last time, I saw several mentions of bugs in it, so I'm not sure
if it's a good choice. I mostly used RapidJSON personally and I didn't have
any problems with it. Being header only is pretty convenient too as it can
be just dropped into any existing object without any problems.

​Been using cJSON for several years now to communicate with various Google, YouTube and Facebook API without a single issue so far

​

 

 So for me the question is really: what's the advantage of having JSON
support in wxWidgets

Hmm.. for completeness? we could also ask: whats the advantages of having wxSocket? wxXmlDocument? wxConfig?

I prefer to have a single library wrapping my classes without the need to fetch them from somewhere else

​

itself compared to just using RapidJSON (or maybe
another header-only JSON library, it's not the only one)?

 Regards,
VZ

[Vadim Zeitlin]

On Wed, 23 Mar 2016 19:32:57 +0200 Eran Ifrah wrote:

EI> On Wed, Mar 23, 2016 at 7:03 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
EI>

EI> > On Wed, 23 Mar 2016 15:08:48 +0200 Eran Ifrah wrote:
EI> >

EI> > EI> For couple of years now, I found myself keep writing wrappers for
EI> > parsing
EI> > EI> and writing JSON objects for my usage with my various wxWidgets
EI> > projects.
EI> >
EI> > Why is it necessary to wrap anything? I just use whichever external JSON
EI> > library the project is using together with wxWidgets.
EI> >
EI> Why not? the C API is not that great... and given that wxWidgets is a C++
EI> library...

Yes, but why not just use a C++ library in the first place?

EI> Been using cJSON for several years now to communicate with various
EI> Google, YouTube and Facebook API without a single issue so far

All the better, but it does come pretty bad in the "Conformance" section
of https://github.com/miloyip/nativejson-benchmark. In fact you would be
hard-pressed to find any reason to prefer cJSON to other libraries from
looking at this page...

EI> > So for me the question is really: what's the advantage of having JSON
EI> > support in wxWidgets
EI>
EI> Hmm.. for completeness? we could also ask: whats the advantages of having
EI> wxSocket? wxXmlDocument? wxConfig?

I would have absolutely never added wxSocket to wxWidgets today when we
have ASIO which is incomparably better than it in all aspects.
wxXmlDocument is used by the library itself, to load XRC, so we can't
really do without it. As for wxConfig, back then (in 1997) there was
nothing similar and I don't know if anything exists now.

EI> I prefer to have a single library wrapping my classes without the need to
EI> fetch them from somewhere else

wxWidgets can't have everything. Yes, JSON is simple enough to be just
about borderline (unlike, say, database access or sockets which were both
clearly mistakes...), but I'm really not convinced there is any advantage
in having it inside instead of using an outside library.

EI> > itself compared to just using RapidJSON (or maybe
EI> > another header-only JSON library, it's not the only one)?

BTW, I didn't use it yet but the library which I'd choose to use right now
if I was starting a new project would be this one:

https://github.com/nlohmann/json

It is header-only, its API looks nice, it has good conformance score and
performance numbers and it has an extensive test suite (even using CATCH
which is my favourite unit testing framework nowadays). Try using it
instead of wrapping cJSON, I'd be curious to know if you really find it
less convenient -- and if you do, at least we'll know why.

Regards,
VZ

[Eran Ifrah]

On Wed, Mar 23, 2016 at 7:43 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:

On Wed, 23 Mar 2016 19:32:57 +0200 Eran Ifrah wrote:

EI> On Wed, Mar 23, 2016 at 7:03 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
EI>
EI> > On Wed, 23 Mar 2016 15:08:48 +0200 Eran Ifrah wrote:
EI> >
EI> > EI> For couple of years now, I found myself keep writing wrappers for
EI> > parsing
EI> > EI> and writing JSON objects for my usage with my various wxWidgets
EI> > projects.
EI> >
EI> >  Why is it necessary to wrap anything? I just use whichever external JSON
EI> > library the project is using together with wxWidgets.
EI> >
EI> Why not? the C API is not that great... and given that wxWidgets is a C++
EI> library...

 Yes, but why not just use a C++ library in the first place?

This discussion is going to the wrong place... I used cJSON because this was the first I found couple of years ago and I never bothered to search for another JSON library since. I am not fixated on wrapping this one. The question is in principle "are you willing to accept new JSON wrapper"

It does not have to be cJSON...

​

 

EI> Been using cJSON for several years now to communicate with various
EI> Google, YouTube and Facebook API without a single issue so far

 All the better, but it does come pretty bad in the "Conformance" section
of https://github.com/miloyip/nativejson-benchmark. In fact you would be
hard-pressed to find any reason to prefer cJSON to other libraries from
looking at this page...

EI> >  So for me the question is really: what's the advantage of having JSON
EI> > support in wxWidgets
EI>
EI> Hmm.. for completeness? we could also ask: whats the advantages of having
EI> wxSocket? wxXmlDocument? wxConfig?

 I would have absolutely never added wxSocket to wxWidgets today when we
have ASIO

​Which requires using boost ​

 

​(which I am using at work...) but its too bloated and I prefer having a single "big" library in my projects

​unless I really have too​

​

which is incomparably better than it in all aspects.
wxXmlDocument is used by the library itself, to load XRC, so we can't
really do without it. As for wxConfig, back then (in 1997) there was
nothing similar and I don't know if anything exists now.

EI> I prefer to have a single library wrapping my classes without the need to
EI> fetch them from somewhere else

​This is pretty much basics these days (having JSON support in the library)

​

 

 wxWidgets can't have everything. Yes, JSON is simple enough to be just
about borderline (unlike, say, database access or sockets which were both
clearly mistakes...), but I'm really not convinced there is any advantage
in having it inside instead of using an outside library.

EI> > itself compared to just using RapidJSON (or maybe
EI> > another header-only JSON library, it's not the only one)?

 BTW, I didn't use it yet but the library which I'd choose to use right now
if I was starting a new project would be this one:

        https://github.com/nlohmann/json

It is header-only, its API looks nice, it has good conformance score and
performance numbers and it has an extensive test suite (even using CATCH
which is my favourite unit testing framework nowadays). Try using it
instead of wrapping cJSON, I'd be curious to know if you really find it
less convenient -- and if you do, at least we'll know why.

 Regards,
VZ

[Vadim Zeitlin]

On Wed, 23 Mar 2016 19:50:07 +0200 Eran Ifrah wrote:

EI> This discussion is going to the wrong place... I used cJSON because this
EI> was the first I found couple of years ago and I never bothered to search
EI> for another JSON library since. I am not fixated on wrapping this one. The
EI> question is in principle "are you willing to accept new JSON wrapper"
EI> It does not have to be cJSON...

So suppose we drop nlohmann/json.hpp under include/wx and tell people to
use it. Would this be enough?

EI> > I would have absolutely never added wxSocket to wxWidgets today when we
EI> > have ASIO
EI>
EI> ​Which requires using boost ​

No, it exists as Boost.ASIO and non-Boost standalone library. It does
require OpenSSL though, but this is just the way it is.

EI> This is pretty much basics these days (having JSON support in the library)

I agree in the sense that people probably do expect to find it in wx. But
I also think people are wrong and we should just explain clearly why there
is no need to have JSON support inside wxWidgets itself.

Regards,
VZ

[Eran Ifrah]

On Wed, Mar 23, 2016 at 8:13 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:

On Wed, 23 Mar 2016 19:50:07 +0200 Eran Ifrah wrote:

EI> This discussion is going to the wrong place... I used cJSON because this
EI> was the first I found couple of years ago and I never bothered to search
EI> for another JSON library since. I am not fixated on wrapping this one. The
EI> question is in principle "are you willing to accept new JSON wrapper"
EI> It does not have to be cJSON...

 So suppose we drop nlohmann/json.hpp under include/wx and tell people to
use it. Would this be enough?

 

​This looks very nice, however the library requirements are a bit strict: GCC 4.9 and above (for me it will do the trick)

​

 

EI> >  I would have absolutely never added wxSocket to wxWidgets today when we
EI> > have ASIO
EI>
EI> ​Which requires using boost ​

 No, it exists as Boost.ASIO and non-Boost standalone library. It does
require OpenSSL though, but this is just the way it is.

EI> This is pretty much basics these days (having JSON support in the library)

 I agree in the sense that people probably do expect to find it in wx. But
I also think people are wrong and we should just explain clearly why there
is no need to have JSON support inside wxWidgets itself.

 Regards,
VZ

[Igor Korot]

Vadim, Eran,

On Wed, Mar 23, 2016 at 2:23 PM, Eran Ifrah <eran....@gmail.com> wrote:
>
>
> On Wed, Mar 23, 2016 at 8:13 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
>>
>> On Wed, 23 Mar 2016 19:50:07 +0200 Eran Ifrah wrote:
>>
>> EI> This discussion is going to the wrong place... I used cJSON because
>> this
>> EI> was the first I found couple of years ago and I never bothered to
>> search
>> EI> for another JSON library since. I am not fixated on wrapping this one.
>> The
>> EI> question is in principle "are you willing to accept new JSON wrapper"
>> EI> It does not have to be cJSON...
>>
>> So suppose we drop nlohmann/json.hpp under include/wx and tell people to
>> use it. Would this be enough?
>>
>
> This looks very nice, however the library requirements are a bit strict: GCC
> 4.9 and above (for me it will do the trick)

Who is going to write the doc and sample on how to use it?

Thank you.

>
>
>>
>> EI> > I would have absolutely never added wxSocket to wxWidgets today
>> when we
>> EI> > have ASIO
>> EI>
>> EI> Which requires using boost
>>
>> No, it exists as Boost.ASIO and non-Boost standalone library. It does
>> require OpenSSL though, but this is just the way it is.
>>
>> EI> This is pretty much basics these days (having JSON support in the
>> library)
>>
>> I agree in the sense that people probably do expect to find it in wx. But
>> I also think people are wrong and we should just explain clearly why there
>> is no need to have JSON support inside wxWidgets itself.
>>
>> Regards,
>> VZ
>
>
>
>
> --
> Eran Ifrah,
> Author of codelite, a cross platform open source C/C++ IDE:
> http://www.codelite.org
> CodeLite IDE Blog: http://codeliteide.blogspot.com/
>

[Iwbnwif Yiw]

​Which requires using boost ​

 

​(which I am using at work...) but its too bloated and I prefer having a single "big" library in my projects

​unless I really have too​​

 

Sorry to jump in on this thread, but I would like to add support for Eran's position.

As a relative programming newbie, one of the fantastic things about wxWidgets is that it has such a broad and diverse range of features. This makes it an excellent 'one stop shop' for all but the most complex or esoteric applications. (By the way, it is testament to the developers that even such a broad library can compile into small apps that run nicely on a Raspberry Pi).

I would have absolutely never added wxSocket to wxWidgets today when we have ASIO which is incomparably better than it in all aspects. 

Well, I am very glad that you did. When I wanted to write a quick program to ping statuses between some Linux servers, I was able to do so in a couple of hours using wxSockets. It would have taken me 4 times as long to search the web, find out that ASIO was the best library, figure out how to use it, build it (probably having dependency nightmares) and integrate it into my program etc.

Having wxSocket right there in wxWidgets means that the classes play nicely with the rest of the framework, but most importantly the documentation is in one place and in one style, and there is even an example in the wxWidgets samples folder :) Please feel free to call me lazy, doubtless it's true, but for a beginner this stuff is great!

I absolutely understand that each expansion of wxWidgets increases the size of the headache for the maintainers. I just want to say that integrating these libraries and wrapping them wxWidgets-style is fantastic for me (and surely other learners). Bring it on!

[Bryan Petty]

On Wed, Mar 23, 2016 at 11:32 AM, Eran Ifrah <eran....@gmail.com> wrote:
>> Why is it necessary to wrap anything? I just use whichever external JSON
>> library the project is using together with wxWidgets.
>>
> Why not?

It's definitely not that simple, some other things to consider:

1. Are additional license restrictions compatible with the wxWidgets license?
2. Do users need to include another copyright attribution notice in
their documentation for redistribution?
3. Are you ready to lock in specific versions of that 3rd party
library into the wxWidgets stable release branching strategy?
- You won't have the same flexibility to just update the 3rd party
library itself without upgrading to new versions of wxWidgets, which
can become problematic.
4. Do we have the resources (i.e. time) to spend maintaining updates
along with additional non-3rd-party patches that expand support to
additional wxWidgets-supported platforms that aren't supported by the
library itself?
- This could include breaking some performance or even compatible
API, or some combination of staying back on old, unsupported versions
of the library because they dropped support for compilers we still
support.

Try to consider past performance (and frustrations) with Scintilla,
libxml, expat, libtiff, and libjpeg updates.

Maybe the best option is *not* to encourage locking into one vendor
considering the wide array of available libraries, especially if
there's absolutely nothing in the core wxWidgets library that uses
JSON itself anyway.

--
Regards,
Bryan Petty

[Wolf]

On , Vadim Zeitlin wrote:

> [..]

>
> I would have absolutely never added wxSocket to wxWidgets today when we
> have ASIO which is incomparably better than it in all aspects.
> wxXmlDocument is used by the library itself, to load XRC, so we can't
> really do without it. As for wxConfig, back then (in 1997) there was
> nothing similar and I don't know if anything exists now.
>

> [..]

Out fo curiosity, did you ever considered dropping them sometime in the future?

W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[Vadim Zeitlin]

On Thu, 24 Mar 2016 17:28:27 +0100 Wolf wrote:

W> On , Vadim Zeitlin wrote:
W>
W> > I would have absolutely never added wxSocket to wxWidgets today when we
W> > have ASIO which is incomparably better than it in all aspects.
W> > wxXmlDocument is used by the library itself, to load XRC, so we can't
W> > really do without it. As for wxConfig, back then (in 1997) there was
W> > nothing similar and I don't know if anything exists now.
W>
W> Out fo curiosity, did you ever considered dropping them sometime in the
W> future?

I don't think it's realistic to drop wxSocket, there is too much code
using it. It's also unfortunately impossible to implement it as a wrapper
around some other library because it has so peculiar[*] semantics. As for
the others, they're not really that burdensome and we do still need
wxXmlDocument so the most that could happen to it would be dropping Expat
and reimplementing it using some other XML library, but it doesn't seem to
be worth it. Finally, wxConfig is somewhat related to the GUI as GUI
programs need to store their settings somewhere and, indeed, wxPersistent
stuff inside the library does use it.

So, no, it seems very unlikely that any of these classes is going to be
removed. I would dearly like to deprecate wxSocket and the entire "net"
library though, it's an embarrassment.

Regards,
VZ

[*] I'm trying hard to be polite here.