json, rather sooner than later

[Stefan Eissing <st...@greenbytes.de>]

Hey, I'm currently evaluating some addition to httpd that needs to parse/serialize JSON. 
I know not everyone is a fan of that format, but some protocols do require it (I try to 
spare us a discussion about "better" formats :-).

Does anyone have ideas/preferences about bringing JSON into httpd (and eventually into
the APR at some later point in time)? I have not found a good lib that is available 
everywhere. Several have MIT license, but I think we cannot somehow bring those under
the Apache umbrella, right?

If anyone has a recommendation or more experience in this then me, I'd be glad for any
guidance.

-Stefan

Re: json, rather sooner than later

[Eric Covener <co...@gmail.com>]

On Fri, Mar 31, 2017 at 9:26 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
> Ok, if I understand you right, this we would add as an external dependency,
> detected via configure and friends and used from a new module. Then linking
> in a MIT API should be just fine.
>
> But how about using JSON in Apache core? How would we do that? Do we have to
> build then smth on our own in order to have it available on all platform, a
> non-optional part for others to build on?

There are probably multiple options / patterns to follow.

ldap stuff in mod_ldap (util_ldap.c)
xml stuff in apr-util
pcre wrapped by ap_*

One motivation to do more than just detect/link would be to get it to
use pools in a clean/consistent way.
Another might be namespacing it.


-- 
Eric Covener
covener@gmail.com

Re: json, rather sooner than later

[Stefan Eissing <st...@greenbytes.de>]

> Am 31.03.2017 um 15:21 schrieb Eric Covener <co...@gmail.com>:
> 
> On Fri, Mar 31, 2017 at 8:51 AM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>> Hey, I'm currently evaluating some addition to httpd that needs to parse/serialize JSON.
>> I know not everyone is a fan of that format, but some protocols do require it (I try to
>> spare us a discussion about "better" formats :-).
>> 
>> Does anyone have ideas/preferences about bringing JSON into httpd (and eventually into
>> the APR at some later point in time)? I have not found a good lib that is available
>> everywhere. Several have MIT license, but I think we cannot somehow bring those under
>> the Apache umbrella, right?
>> 
> 
> I've helped a team that used jansson in a module, it seems pretty solid.
> But I didn't work much with the API.
> 
> MIT should not be an issue at all, though.

Ok, if I understand you right, this we would add as an external dependency,
detected via configure and friends and used from a new module. Then linking
in a MIT API should be just fine.

But how about using JSON in Apache core? How would we do that? Do we have to
build then smth on our own in order to have it available on all platform, a
non-optional part for others to build on?

> -- 
> Eric Covener
> covener@gmail.com

Re: json, rather sooner than later

[Eric Covener <co...@gmail.com>]

On Fri, Mar 31, 2017 at 8:51 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
> Hey, I'm currently evaluating some addition to httpd that needs to parse/serialize JSON.
> I know not everyone is a fan of that format, but some protocols do require it (I try to
> spare us a discussion about "better" formats :-).
>
> Does anyone have ideas/preferences about bringing JSON into httpd (and eventually into
> the APR at some later point in time)? I have not found a good lib that is available
> everywhere. Several have MIT license, but I think we cannot somehow bring those under
> the Apache umbrella, right?
>

I've helped a team that used jansson in a module, it seems pretty solid.
But I didn't work much with the API.

MIT should not be an issue at all, though.

-- 
Eric Covener
covener@gmail.com

Re: json, rather sooner than later

[Jim Jagielski <ji...@jaguNET.com>]

> On Mar 31, 2017, at 9:31 AM, Graham Leggett <mi...@sharp.fm> wrote:
> 
> 
> I would model this the same way we model XML - we have a compatibility layer in APR, and support one (maybe more) json parsers.
> 
> Definite +1 to the concept, and given that YAML is now the new hipster cool, we might do that at the same/similar time.
> 

+1 to both

Re: json, rather sooner than later

[Graham Leggett <mi...@sharp.fm>]

On 31 Mar 2017, at 2:51 PM, Stefan Eissing <st...@greenbytes.de> wrote:

> Hey, I'm currently evaluating some addition to httpd that needs to parse/serialize JSON. 
> I know not everyone is a fan of that format, but some protocols do require it (I try to 
> spare us a discussion about "better" formats :-).
> 
> Does anyone have ideas/preferences about bringing JSON into httpd (and eventually into
> the APR at some later point in time)? I have not found a good lib that is available 
> everywhere. Several have MIT license, but I think we cannot somehow bring those under
> the Apache umbrella, right?
> 
> If anyone has a recommendation or more experience in this then me, I'd be glad for any
> guidance.

I would model this the same way we model XML - we have a compatibility layer in APR, and support one (maybe more) json parsers.

Definite +1 to the concept, and given that YAML is now the new hipster cool, we might do that at the same/similar time.

Regards,
Graham
—

Re: json, rather sooner than later

[Nick Kew <ni...@apache.org>]

> On 31 Mar 2017, at 13:51, Stefan Eissing <st...@greenbytes.de> wrote:
> 
> Hey, I'm currently evaluating some addition to httpd that needs to parse/serialize JSON. 
> I know not everyone is a fan of that format, but some protocols do require it (I try to 
> spare us a discussion about "better" formats :-).
> 
> Does anyone have ideas/preferences about bringing JSON into httpd (and eventually into
> the APR at some later point in time)? I have not found a good lib that is available 
> everywhere. Several have MIT license, but I think we cannot somehow bring those under
> the Apache umbrella, right?
> 
> If anyone has a recommendation or more experience in this then me, I'd be glad for any
> guidance.
> 
> -Stefan

+1 to a JSON module.

Not sure if there’s mileage in abstracting JSON parsers: when I last looked,
each had its own data models at a higher level than could be usefully unified.
But I’m open to persuasion.

I did some work on this, albeit for a subset of JSON required by a particular project.
I’ll try & dig that up, to see if there’s anything worth salvaging.

— 
Nick Kew