Re: JSON in OTP

Thanks for the replies. I just thought it's convenient that a standard
library provides convenient stuff, but a good package system can do
that as well.

I assumed these libraries (jsx, jsone, jiffy) would be stable by now
and wouldn't need much maintainance, so you could just take one of them
in, but I guess I was wrong. These three all have recent commits.

JSON doesn't seem to be in all other high-level langauges' standard
libraries either (Python: yes; Perl: no; PHP: yes; Java: no; Elixir:
no; Haskell: no). Package systems seem to solve it instead.

One problem with multi-level dependencies is that if each of your
dependencies depend on a different JSON implementation (or a different
version), you may end up depending on several different
implementations. But if you decouple the encoding/decoding from
libraries doing things like JSON Schema, JSON RPC, etc. and only pass
them the parse tree, you avoid this. I guess this is good style anyway.
At least there is a de-facto standard parse tree representation by now.

So I guess you're right being restrictive. How about deprecating inets?
xmerl? parts of zlib/zip (there's some overlap)? I guess you're already
thinging hard about what can be removed...

BR/
Viktor


On Wed, 2020-11-04 at 17:11 +0100, Kenneth Lundin wrote:
> The answer is that looking back maybe we should have added JSON
> encode/decode to OTP 12 years ago, but now there are a number of good
> separate JSON libraries
> outside OTP so why should we (the OTP team) take on the task of
> developing and maintaining a JSON library.
> Why is it better to include the JSON lib in OTP than to have it
> separate?
> We have:
> jsx, jsone, jiffy, .... to name a few
> 
> We or someone else could create an OTP+ distribution which includes
> OTP + other popular non OTP applications. I even think Erlang
> Solutions has done that at some point.
> 
> /Kenneth, Erlang/OTP, Ericsson
> 
> On Mon, Nov 2, 2020 at 10:39 PM Viktor Söderqvist <
> [email protected]> wrote:
> > 12 years have passed since EEP 18. [1] Since then, maps have been
> > added
> > to Erlang and the string module has been made accept binaries. This
> > makes up a more obvious representation of JSON than in 2005 [2].
> > 
> > If anyone was arguing that OTP is made for telecom and not web
> > development, this argument doesn't hold anymore, now that the
> > telecom
> > standards are replacing GTP and Diameter with HTTP and JSON.
> > 
> > The 5G mobile network specifications are full of JSON, REST and
> > HTTP/2
> > (e.g. 3GPP TS 29.500 [3]) and in 3GPP TS 29.501 [4] things like
> > HATEOAS, OpenAPI specifications using JSON Schema and YAML files
> > and
> > how JSON documents should be patched using HTTP PATCH requests are
> > covered. (Other interesting 5G specs are 23.501 [5] and 23.502
> > [6].)
> > 
> > JSON has also been standardized as ECMA-404 [7] in 2017.
> > 
> > Is it time to re-evaluate adding json:{encode,decode}/1 in OTP? Or
> > are
> > the arguments against it still valid?
> > 
> > Regards,
> > Viktor
> > 
> > [1]: http://erlang.org/eeps/eep-0018.html
> > [2]: 
> > http://erlang.org/pipermail/erlang-questions/2005-November/017805.html
> > [3]: https://www.3gpp.org/DynaReport/29500.htm (Click the Versions
> > tab,
> > then click a linked version number to download a zip file which
> > contains a Word document, which can be converted to a readable
> > format...)
> > [4]: https://www.3gpp.org/DynaReport/29501.htm
> > [5]: https://www.3gpp.org/DynaReport/23501.htm
> > [6]: https://www.3gpp.org/DynaReport/23502.htm
> > [7]: 
> > http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
> >