<div dir="ltr">Hi everyone!<div><br></div><div>I would like to address some of the questions and comments in this discussion. I will be brief and get into more details once I get back to Stockholm.</div><div><br></div><div>1. The Package Manager client should (will/must) be written completely in Erlang. There are many reasons for this. For instance, it is easier to maintain an application written in a language we have some familiarity with. It is a nicer fit. We can have the client the client in the bootstrap and let it upgrade itself once downloaded. I don't think OTP can really be satisfied with anything else than a PM written it in Erlang. =)</div><div><br></div><div>2. Scope it down. For starters the Package Manager should only handle Erlang applications. Things like Erl_Interface and JInterface are the odd one outs in the lib directory today and they don't really fit here. At least not how I envision it. I'm sure we could jury-rig something but we should not start there. This also mean that we should *not* handle OS dev-libs in our package-manager. We can have a specialized description field for such things, telling the developer he needs to install them prior to installing an Erlang application but we should not handle it beyond that.</div><div><br></div><div>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.</div><div><br></div><div>I hesitate to discuss the naming of this thing in fear of something exploding. But, I will throw my hat into the race .. Gear (client) and Gearbox (server). Gear - Erlang Application Repositories. With commands like "gear up .." for upgrading packages and "gear down" for downgrading them.</div><div><br></div><div>Great discussion, have to run,</div><div>Björn-Egil - did not review my comments before submitting.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-03 13:27 GMT+01:00 Imants Cekusins <span dir="ltr"><<a href="mailto:imantc@gmail.com" target="_blank">imantc@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Well a parse transform could sanitize the config files so only acceptable statements are used.</p>
<p dir="ltr">Maybe use a different extension for the config files.</p>
<p dir="ltr">The key benefits are familiar syntax & syntax checks.</p>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>