[erlang-questions] modular otp concerns

[Richard A. O'Keefe]

> On Tue, Feb 18, 2014 at 9:11 AM, Vlad Dumitrescu <vladdu55@REDACTED> wrote:
> One thought about this: there are several levels of modularity that could be enabled, but as a first step I think that what could be separated are the telecom-specific libraries (asn1, cos*, megaco, diameter). Snmp is on the fence.

What makes you think ASN.1 is telecom-specific?

We're not doing it at the moment, but my Information
Retrieval expert colleague once had to deal with
documents stored in an ASN.1 format.  As far as I
know that collection still works that way.

According to
http://www.itu.int/dms_pub/itu-t/oth/0B/04/T0B040000422C01PDFE.pdf
"ASN.1 is being increasingly used outside the telecommunication
industry in areas such as security, transportation, Smart Grid,
genetic research and many others.  Logistics: <companies>.
Electrical Smart Grid: <companies>. Information network: <companies>."

The web site for the Open Source ASN.1 Compiler asn1c says
http://lionet.info/asn1c/basics.html
"If you are using SSL (HTTPS) to access a bank or email account,
be sure the ASN.1 is involved too; it describes the structure of
the server's identity certificate for verification by your
Internet browser."

You never know what you're going to need...

Let me advert once again to R.

The CRAN archive has 5224 packages at the moment.
I have only 244 of them installed (less than 5%).
I probably _asked_ for about 80 of them, the rest
being automatically installed dependencies.
Tomorrow I may discover that I need one of the
remaining 4980.

If I am at home and we've used up our monthly
quota (which happens) I am completely stuck.
If I had the lot on a DVD, I'd be away laughing.

If I'm at work, it's no harder to install over the
internet than it is from a local file; apart from
saying what I want I don't get involved.  (I do not
have to manually check package hashes, I don't have
to remember to use https, I don't have to provide a
superuser password.)

But the packages are *there*, *documented*,
*versioned*, and *tested*, and all of that testing
gets redone whenever there is a new release.

Considering what Erlang's used for, it doesn't matter
very much if chunks of OTP are split off and pulled
over the net when you need them (during initial testing).

What *does* matter is that they are *managed* and
*tested* and their documentation is *managed* and
*reviewed* as a unit, so that you don't get the
documentation for Erlang 19 with the code of
Erlang version 17, &c.

After unpacking R16B03-1 and building,
otp_src_R16B03-1 is 330+ MB according to 'du'.
I could fit more than 20 such unpacked 
releases on a cheap memory stick.
The distribution, as a .tar.bz2 file, is j
58½ MB; I could fit 125 of those on a memory
stick.  (Hmm.  Wouldn't that be a cool gimmick
for the next Erlang conference?  Give attendees
a memory stick with every available Erlang
source release on it...  Heck, when an Erlang
speaker presents a conference on another topic,
hand out sticks to everyone that wants them.)

So what is the reason for distributing less than
what's distributed now?


go