<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 1, 2013 at 7:08 PM, Jason Orendorff <span dir="ltr"><<a href="mailto:jason.orendorff@gmail.com" target="_blank">jason.orendorff@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 class="im">On Wed, May 1, 2013 at 9:18 AM, Kevin Smith <<a href="mailto:zenparsing@gmail.com">zenparsing@gmail.com</a>> wrote:<br>

</div><div class="im">> - Dave, your argument that URI's as a naming mechanism is a "failure"<br>
> cherry-picks cases where URIs were obviously overkill.<br>
<br>
</div>What counterexamples should David have mentioned?<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div style>Well, it's Dave's job to come up with one, not mine ; P</div><div style><br></div><div style>Actually, I'm starting to think that the "URI vs. unstructured names" argument is a bit of a tangent.  These are the kinds of arguments to have when designing a packaging system, not the core module system.</div>
<div style><br></div><div style>A clean separation between modules and packages will give us the freedom to experiment with different approaches to inter-package dependency resolution (IPDR, so I don't have to repeat it later).  At the base level, we just want URLs.  Loader hooks can then be used to give special semantics to URI subsets, or even to provide AMD-style URL overloading.*</div>
<div style><br></div><div style>We don't need to solve the IPDR problem with the core module system.  Instead, we can provide the primitives and see what flourishes.</div><div style><br></div><div style>{ Kevin }</div>
<div style><br></div><div style>*Note that CommonJS always blurred the distinction between packages and modules.</div></div></div></div>