[erlang-questions] Erlang package manager

[Tuncer Ayaz]

On Sat, Jan 3, 2015 at 6:16 PM, Tuncer Ayaz wrote:
> On Sat, Jan 3, 2015 at 3:54 PM, Bjorn-Egil Dahlberg wrote:
> > Hi everyone!

[...]

> > 3. Protocols first. I saw someone mentioning this already and it
> > made me so happy. Protocols first is perhaps a misnomer but it is
> > important anyway. We have several languages that runs ontop of
> > beam or Erlang. Elixir has its own package manger Hex (client) and
> > Hexweb (server) and I think it is a good thing if we use
> > compatible protocols. Http and restful protocols is all the rage
> > and I don't any reason to sidestep that. My vision here is a
> > common protocol bus and the client can query any server for Erlang
> > applications, i.e. Hex can query an Erlang Application provider
> > for updates and install them. I think this only affect us (Erlang)
> > by pressuring us to formalize our rest protocols / api .. but that
> > is a good thing.
>
> As long as we're not held back by limitations of existing protocols,
> and are free to improve/extend, sure, it's a good approach.

Thinking about, it appears what you're actually suggesting is a smart
http protocol which would disallow easy mirroring. If that's the case,
then it's a bad idea.

I've explained this in my initial response to Bruce, but I'll try to
summarize the benefits of a simple files+dirs structure served via
http/ftp/_whatever_:

* Like mirrors for CTAN, anyone who wishes to host a mirror can do so
easily alongside CTAN, *nix distros, etc., without the need for a
special CGI script or extra http daemon. This greatly increases the
reliability and availability by avoiding the need for a centrally
managed and to-be-accessed smart host that has to be paid for and
administered. No matter how professional and CDN'ed something is, it
will eventually go down for a period. Using a conventionally
mirror'able structure avoids "is foo.erlang.org down?" questions and
broken builds, as users will by convention use mirrors instead of a
central location. For this to be a non-issue, we'd have to have van
Jacobson's content-centric networking (or one of the derivatives) in
addition to more reliable global network links.

* It's easy to set up public or private mirrors.

* In case of problems, it gives you the option of restoring or
checking the integrity of files by making use several independent,
trusted mirrors that hadn't been updated to the problematic state yet.

That said, it's perfectly fine to have one or more registries where
stuff is published to and mirrored from.