<div dir="ltr">Hi!<div><br></div><div>This would be a very useful thing to implement, IMHO. </div><div><br></div><div>The chunks could also be located in a zip archive, or online, so maybe a {uri, URI} value is more general than a {path, Path} one? For example, the docs for OTP would be much easier to distribute as an archive that doesn't need to be unpacked than one that has to be unpacked at the right place and create hundreds of small files. Similarily, if the docs are not available locally, they could be retrieved from a URL and cached locally.</div><div><br></div><div>Actually, why restrict this to handling the documentation? If the information about the module is moved as an item in Docs (at the cost of non-uniform key structure), then the top-level is generic and can be used to store all kinds of metadata about code entities (making Docs a map where 'docs' is just one of the keys). I have an use-case (cross-reference information), and maybe even dialyzer could store plt data in this distributed manner (not sure if it would work or help, just guessing).<br></div><div><br></div><div>On the other hand, these different kind of data would better be kept separate, it's not really needed to use a single chunk. But the basic tools to create and use these chunks can very well be common, I think. </div><div><br></div><div>best regards,<br></div><div>Vlad</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 4, 2018 at 10:59 PM, José Valim <span dir="ltr"><<a href="mailto:jose.valim@gmail.com" target="_blank">jose.valim@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>This EEP proposes an official API documentation storage to be used by</div><div>by BEAM languages.  By standardizing how API documentation is stored,</div><div>it will be possible to write tools that work across languages.</div><div><br></div><div>I want to thank Eric and Radek, who co-authored the proposal, as well as</div><div>Kenneth, Fred, Tristan and Loïc for their feedback.</div><div><br></div><div>See the attached document.</div><span class="HOEnZb"><font color="#888888"><div><div class="m_3383220298187739340gmail_signature"><div dir="ltr"><div><div><br></div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><b><span style="border-collapse:separate;font-family:arial;font-weight:normal"><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><b>José Valim</b></span></div><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><div><span style="font-family:verdana,sans-serif;font-size:x-small"><a href="http://www.plataformatec.com.br/" style="color:rgb(42,93,176)" target="_blank">www.plataformatec.com.br</a></span></div><div><span style="font-family:verdana,sans-serif;font-size:x-small">Founder and </span><b><span style="border-collapse:separate;font-family:arial;font-weight:normal"><div style="display:inline"><span style="font-family:verdana,sans-serif;font-size:x-small">Director of R&D</span></div></span></b></div></span></div></span></b></span></div></div></div></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
eeps mailing list<br>
<a href="mailto:eeps@erlang.org">eeps@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/eeps" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/eeps</a><br>
<br></blockquote></div><br></div>