<div dir="ltr">
















<p class="MsoNormal"> Hi,</p>

<p class="MsoNormal"> <br></p>

<p class="MsoNormal"><span style="font-size:9.5pt;font-family:Arial;background-image:initial;background-repeat:initial">ASN.1 isn't just a
"transfer-format", it's something OTP itself *uses*. Without the
ASN.1 application, there would be no public_key application, and therefore no
SSL, to name one.</span><span style="font-size:9.5pt;font-family:Arial"><br>
<br>
<span style="background-image:initial;background-repeat:initial">JSON would be just sitting there. What's the
point?</span></span></p>

<p class="MsoNormal"><span style="font-size:9.5pt;font-family:Arial;background-image:initial;background-repeat:initial"> </span></p>

<p class="MsoNormal"><Theepan>If I argue to your point -- not all the
libraries in the STDLIB are used internally. Moreover, in a software
development platform, libraries are not just meant to be used
internally.</Theepan><span style="font-size:9.5pt;font-family:Arial"><br>
<br>
<span style="background-image:initial;background-repeat:initial">Another argument against it is one you cited in
your email: there are already a variety of open source JSON libraries. Each has
different properties and are useful to different people. Why would you include
one and basically doom the others? Which one would you bundle? Will that choice
make sense to everyone?</span></span></p>

<p class="MsoNormal"><span style="font-size:9.5pt;font-family:Arial;background-image:initial;background-repeat:initial"> </span></p>

<p class="MsoNormal"><span style="font-size:9.5pt;font-family:Arial;background-image:initial;background-repeat:initial"><Theepan></span> The library
that caters to the language necessities, that imposes better coding practice,
that performs better, that is hardware efficient should be included, may be
with modifications. If the libraries are out in the wild, the developer will spend their valuable time in selecting the library , than concentrating on solving the business problem.</p>

<p class="MsoNormal"><span style="font-size:9.5pt;font-family:Arial;background-image:initial;background-repeat:initial"></Theepan></span><span style="font-size:9.5pt;font-family:Arial"><br>
<br>
<span style="background-image:initial;background-repeat:initial">Finally, I'm not sure what's the point? If you
are using Erlang.mk, to use jsx, you need to add this single line to your
Makefile:</span><br>
<br>
<span style="background-image:initial;background-repeat:initial">DEPS = jsx</span><br>
<br>
<span style="background-image:initial;background-repeat:initial">If jsx was part of OTP, you would need to add
this single line to your Makefile:</span><br>
<br>
<span style="background-image:initial;background-repeat:initial">OTP_DEPS = jsx</span></span></p>

<p class="MsoNormal"><span style="font-size:9.5pt;font-family:Arial;background-image:initial;background-repeat:initial"> </span></p>

<p class="MsoNormal"><span style="font-size:9.5pt;font-family:Arial;background-image:initial;background-repeat:initial"><Theepan>How you
include it into the build is not the issue. It does not have to be through
Erlang.mk. There are couple of other package management systems for Erlang.
Also, after a direct install, you can simply refer it in the release file in
one line. The issue is not of technical nature, but the bigger picture.
Continuity/Faster sync with Erlang evolutions/Simplicity/Regulation/Completeness.
etc</Theepan></span><span style="font-size:9.5pt;font-family:Arial"><br>
<br>
<span style="background-image:initial;background-repeat:initial">The advantage of bundling it in OTP are not
obvious, to say the least.</span><br>
<br>
<span style="background-image:initial;background-repeat:initial">In general I believe OTP should reduce the
number of libraries it comes with, not increase it. It's easy to find a library
fitting your needs nowadays. Erlang.mk for example has 470 packages and you can
search them in one easy command: make search q=json</span></span></p>

<p class="MsoNormal"><span style="font-size:9.5pt;font-family:Arial;background-image:initial;background-repeat:initial"> </span></p>

<p class="MsoNormal"><span style="font-size:9.5pt;font-family:Arial;background-image:initial;background-repeat:initial"><Theepan>As a software
development, developers would not expect to have fragmentation of libraries. As
I already mentioned, Erlang.mk is not the only Erlang package management out
there, but it is not the issue here. JSON library is a good candidate to be including into the STDLIB, with of course bounds on loose definitions like JavaScript engines do.</Theepan></span></p>

<p class="MsoNormal"> </p>

</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 7, 2015 at 1:09 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 09/07/2015 03:34 AM, Theepan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Team,<br>
<br>
Is there any reason why a JSON library is not included into Erlang/OTP<br>
releases? Since it was initially planned for telco systems, it includes<br>
ASN.1 library. It has some other transfer-format libraries as well.<br>
</blockquote>
<br></span>
ASN.1 isn't just a "transfer-format", it's something OTP itself *uses*. Without the ASN.1 application, there would be no public_key application, and therefore no SSL, to name one.<br>
<br>
JSON would be just sitting there. What's the point?<br>
<br>
Another argument against it is one you cited in your email: there are already a variety of open source JSON libraries. Each has different properties and are useful to different people. Why would you include one and basically doom the others? Which one would you bundle? Will that choice make sense to everyone?<br>
<br>
Finally, I'm not sure what's the point? If you are using Erlang.mk, to use jsx, you need to add this single line to your Makefile:<br>
<br>
DEPS = jsx<br>
<br>
If jsx was part of OTP, you would need to add this single line to your Makefile:<br>
<br>
OTP_DEPS = jsx<br>
<br>
The advantage of bundling it in OTP are not obvious, to say the least.<br>
<br>
In general I believe OTP should reduce the number of libraries it comes with, not increase it. It's easy to find a library fitting your needs nowadays. Erlang.mk for example has 470 packages and you can search them in one easy command: make search q=json<br>
<br>
Cheers,<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Loïc Hoguin<br>
<a href="http://ninenines.eu" rel="noreferrer" target="_blank">http://ninenines.eu</a><br>
Author of The Erlanger Playbook,<br>
A book about software development using Erlang<br>
</font></span></blockquote></div><br></div>